From gonzalo.camarillo@ericsson.com Sun Mar 1 03:09: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 161563A696F for ; Sun, 1 Mar 2009 03:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.461 X-Spam-Level: X-Spam-Status: No, score=-4.461 tagged_above=-999 required=5 tests=[AWL=1.788, BAYES_00=-2.599, HELO_EQ_SE=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 NtHjUR9R4IAU for ; Sun, 1 Mar 2009 03:09:28 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D80163A694C for ; Sun, 1 Mar 2009 03:09:27 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0079B204A5; Sun, 1 Mar 2009 12:09:49 +0100 (CET) X-AuditID: c1b4fb3e-b00a2bb0000023da-70-49aa6cfdd2a6 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 296C220484; Sun, 1 Mar 2009 12:09:49 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Mar 2009 12:09:49 +0100 Received: from [131.160.126.131] ([131.160.126.131]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Mar 2009 12:09:48 +0100 Message-ID: <49AA6CFC.2030501@ericsson.com> Date: Sun, 01 Mar 2009 13:09:48 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Magnus Westerlund References: <00fb01c9402b$f0b169e0$c3f0200a@cisco.com> <491974FF.3080106@ericsson.com> In-Reply-To: <491974FF.3080106@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2009 11:09:48.0879 (UTC) FILETIME=[3C76C5F0:01C99A5E] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-behave-turn-ipv6@tools.ietf.org, 'Behave WG' , Dan Wing Subject: Re: [BEHAVE] WGLC: TURN and TURN-IPv6 (draft-ietf-behave-turn-11, draft-ietf-behave-turn-ipv6-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: Sun, 01 Mar 2009 11:09:29 -0000 Hi Magnus, thanks for your comments. Answers inline: > 1. See TURN last call comment about loop attack if address checking as > mitigation is written into the TURN spec, then this needs to be marked > as non effective when implementing this extension. I will work with Philip on this one so that both documents are aligned. > 2. Section 3: > TURN servers allocate a single relayed-transport-address per > allocation request. Therefore, Allocate Requests cannot carry more > than one REQUESTED-ADDRESS-TYPE attribute. Consequently, a client > that wishes to allocate more than one address at a TURN server (e.g., > an IPv4 and an IPv6 address) needs to perform several allocation > requests (one allocation request per address). > > It is not clear how this relates to the rule about a single allocation > per 5-tuple? Is this changing that? No, it is not changing that. The Overview of Operation section is non-normative and, thus, does not change anything. > 3. Section 4.1: > > Reserved: at this point, the 24 bits in the reserved field SHOULD be > set to zero by the client and MUST be ignored by the server. > > I don't like the SHOULD in this sentence. That makes it impossible for > future revisions to be certain that these bits are set to 0. Thus it > makes them unusable for extension. I have changed it to a MUST. > > 4. Section 6: > > TURN > relays performing an IPv4-to-IPv6 or an IPv6-to-IPv4 translations > SHOULD translate other header fields following SIIT (Stateless IP/ > ICMP Translation Algorithm) as described in Sections 3 and 4 of > [RFC2765] respectively. > > I think there need to be some exceptions to this: > > - Source address when translating from v4 to v6: SIIT specifies: > Source Address: > The low-order 32 bits is the IPv4 source address. > The high-order 96 bits is the IPv4-mapped prefix > (::ffff:0:0/96) > > To me it seem that the allocation's relayed IPv6 address should be > used in the client-> peer direction and the servers transport address > in the other. > > - Destination address: > The low-order 32 bits is the IPv4 destination > address. The high-order 96 bits is the IPv4- > translated prefix (0::ffff:0:0:0/96) > > Also in this case it seem that the peer address or the client's server > reflexive address is the one to use. > > In the reverse direction you also to change the address field > specifications: > > Source Address: > If the IPv6 source address is an IPv4-translated > address then the low-order 32 bits of the IPv6 source > address is copied to the IPv4 source address. > Otherwise, the source address is set to 0.0.0.0. The > use of 0.0.0.0 is to avoid completely dropping e.g. > ICMPv6 error messages sent by IPv6-only routers which > makes e.g. traceroute present something for the > IPv6-only hops. > > Destination Address: > IPv6 packets that are translated have an IPv4-mapped > destination address. Thus the low-order 32 bits of > the IPv6 destination address is copied to the IPv4 > destination address. > > > I also think some remarks or reduced scoping is needs as Section 3.4 and > 4.4 are not applicable to TURN address family translations. per other comments we received, the translation sections have been rewritten. The issues you bring up above are addressed in the new text. Thanks, Gonzalo From gonzalo.camarillo@ericsson.com Sun Mar 1 03:37: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 12D9528C0F6 for ; Sun, 1 Mar 2009 03:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.502 X-Spam-Level: X-Spam-Status: No, score=-4.502 tagged_above=-999 required=5 tests=[AWL=1.747, BAYES_00=-2.599, HELO_EQ_SE=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 6FNUUA6VsHxT for ; Sun, 1 Mar 2009 03:37:48 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A92C83A6A35 for ; Sun, 1 Mar 2009 03:37:47 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A4CBD20498; Sun, 1 Mar 2009 12:09:51 +0100 (CET) X-AuditID: c1b4fb3e-ae09ebb0000023da-71-49aa6cff1ca0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7BB1C20484; Sun, 1 Mar 2009 12:09:51 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Mar 2009 12:09:51 +0100 Received: from [131.160.126.131] ([131.160.126.131]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Mar 2009 12:09:50 +0100 Message-ID: <49AA6CFE.3080305@ericsson.com> Date: Sun, 01 Mar 2009 13:09:50 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Philip Matthews References: <3D3387E8-1DEE-4405-AEAD-46706406DD92@magma.ca> In-Reply-To: <3D3387E8-1DEE-4405-AEAD-46706406DD92@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2009 11:09:50.0991 (UTC) FILETIME=[3DB909F0:01C99A5E] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-behave-turn-ipv6@tools.ietf.org, Behave WG Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-ipv6-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: Sun, 01 Mar 2009 11:37:49 -0000 Hi Philip, thanks for your comments. I am adding them to my working copy of the next revision of the draft (06), which I will try to submit shortly. My answers inline: > *) I would like to see the abstract, Introduction, and Overview > sections focus more on the overall idea of adding IPv6 support to > TURN, with the associated concepts of relaying v6-to-v6 and > v4-to-v6/v6-to-v4. Personally, I think that is the big concept that > this draft needs to define. Once that is done, adding a way for the > client to specify the address family of the relayed-transport-address > seems just a little add-on. Done. > *) Must a TURN server implementing this draft support > v4-to-v6/v6-to-v4 relaying? What about v6-to-v6 relaying? Personally, > I feel that a server should be able to conform to this draft if it > just supports the REQUESTED-ADDRESS-TYPE attribute and only relays > v4-to-v4. Whatever decision is made, I think the draft should make a > definite statement on these points. There was another comment on the list on this topic stating that supporting this extension should imply that the server can handle IPv6 packets. Once a server can handle IPv6 packets, it is assumed it can perform the three types of relaying you list above. If there are no good reasons for a server to support only a subset of them, we do not need to add any more complexity here. I have added the following text: "A TURN server that supports a set of address families is assumed to be able to relay packets between them. If a server does not support the address family requested by a client, the server returns a 440 (Address Family not Supported) error response." > *) I think the draft needs to state the following: a) That the client > transport address and the server transport address must use the same > address family; b) That the relayed-transport-address and all peer > transport addresses must use the same address family; c) That the > addresses in permissions and channel bindings are of the same family > as the relayed-transport-address. Actually, points (a) and (b) need > more words, since the actual address families can differ if a NAT64 > or NAT46 sits in the path between the client and the server, or the > server and a peer. What must be true is that the address families as > seen by the client and as seen by the server must be the same. I do not think we need to say anything about a) because from the point of view of the server and of the client, the address families will always be the same. Statements b) and c) go together. I have specified c), which also covers b). > *) This draft proposes an error code 440 "Address Family not > supported". But I think this error code needs to be redefined as > "Requested address family relaying not supported". For example, if a > server supports only v4-to-v4 and v6-to-v6 relaying, and it receives > an Allocate request with a REQUESTED-ADDRESS-TYPE attribute > specifying IPv6 on a IPv4 server address, then the problem is not > that IPv6 is not supported, but that v4-to-v6 relaying is not > supported. See discussion on this point above. > *) I think this draft needs to define an additional error code: "Peer > address family mismatch". This error code is returned whenever a > CreatePermission or ChannelBind request is received with an > XOR-PEER-ADDRESS attribute whose address family does not match the > address family of the relayed-transport-address. Similarly, I think > this draft needs to define what happens when a Send or Data > indication is received where the XOR-PEER-ADDRESS attribute contains > an address of the wrong family. Done as part of the specification of c) above. > *) This draft defines how a TURN server reacts if a Refresh request > contains an (unexpected) REQUESTED-ADDRESS-TYPE attribute. This may > be desirable, but I will note that the base TURN spec says nothing > similar about all the other attribute of TURN. Furthermore, this > draft says nothing about an unexpected REQUESTED-ADDRESS-TYPE > attribute in a CreatePermission, ChannelBind, Send, or Data message. > So I think the WG needs to decide that either such behavior needs to > be specified, or that it does not need to be specified, and the two > drafts updated appropriately. You are right that specifications cannot specify every possible error case. However, they should specify those error cases that appear more often or that are particularly confusing. I think this error case is one of them. So, I suggest we leave it as is. > *) The draft references the SIIT spec (RFC 2765) for the details of > how to translate v4-to-v6 and v6-to-v4. However, the base TURN > specification is carefully written so that a TURN server can be > implemented by a userland process without special privileges, and > unfortunately most of the translations specified by SIIT require > detailed header access of the kind not normally available to an > un-privileged userland process. In my opinion, we want to preserve > this property of TURN, and thus this draft should define translations > that satisfy this constraint. Done. > *) The above comment also applies to the v6-to-v6 relaying rules > specified in section 6 of this draft. Some of the v6-to-v6 rules > specified cannot normally be implemented by an un-privileged userland > process. For example, un-privileged userland processes cannot > typically send ICMP messages. Done. > *) Section 12 of the base TURN spec describes header field processing > in terms of Preferred and Alternate behaviors. I think that section 6 > of this draft should do the same. > > > *) Suggestion: rename REQUESTED-ADDRESS-TYPE to > REQUESTED-ADDRESS-FAMILY. I feel this would make the purpose of the > attribute clearer. Done. From a different email: > Two additional comments. > > *) If the RESERVATION-TOKEN attribute is present in the Allocate > request, then I think the REQUESTED-ADDRESS-TYPE attribute must not > be present, and the address family is determined from the reserved > transport address. Furthermore, I suggest that we allow the Allocate > request containing the RESERVATION-TOKEN attribute to arrive over any > transport (as is done today), including over a different address > family -- thus it is possible that this subsequent request will > involve a different form of relaying. (I.e., the first request might > be v4-to-v4 relaying, while the second is v6-to-v4 relaying). Done. > *) The draft says: > > If the REQUESTED-ADDRESS-TYPE attribute is absent, the server MUST > allocate an IPv4 transport address to the TURN client. > > If the request does not contain a REQUESTED-ADDRESS-TYPE attribute, > then it is from an client that supports only v4-to-v4 relaying. So I > am thinking that the server should reject this request if it arrives > on a v6 server transport address. See discussion on this point above. Thanks, Gonzalo From huitema@windows.microsoft.com Sun Mar 1 18:14: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 0E0163A6A79 for ; Sun, 1 Mar 2009 18:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWb4hNsW7Y1a for ; Sun, 1 Mar 2009 18:14:13 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 19C6E28C10E for ; Sun, 1 Mar 2009 18:13:52 -0800 (PST) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sun, 1 Mar 2009 18:14:17 -0800 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.2.99.4; Sun, 1 Mar 2009 18:14:17 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Sun, 1 Mar 2009 18:14:17 -0800 From: Christian Huitema To: Philip Matthews Date: Sun, 1 Mar 2009 18:14:13 -0800 Thread-Topic: [BEHAVE] TURN-13 posted Thread-Index: AcmZRaUmCDIAemmpSlO69S1PhdsDmgBldEnw Message-ID: <8EFB68EAE061884A8517F2A755E8B60A1CB2853328@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <3975D16E-3CFB-40E0-B208-247A055A9BDB@magma.ca> <8EFB68EAE061884A8517F2A755E8B60A19DB1B29AC@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mahy , Rohan, Behave WG Subject: Re: [BEHAVE] TURN-13 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, 02 Mar 2009 02:14:14 -0000 > Yes. The rules of section 15 of RFC5389 must be followed: > > The value in the length field MUST contain the length of the Value > part of the attribute, prior to padding, measured in bytes. Since > STUN aligns attributes on 32-bit boundaries, attributes whose > content > is not a multiple of 4 bytes are padded with 1, 2, or 3 bytes of > padding so that its value contains a multiple of 4 bytes. The > padding bits are ignored, and may be any value. > > The last bit applies to the EVEN-PORT and DATA attributes of TURN. > > I suppose we could include a sentence in the spec saying this > explicitly, even though the TURN spec does say (section 4): > > TURN is an extension to STUN. All TURN messages, with the exception > of the ChannelData message, are STUN-formatted messages. All the > base processing rules described in [RFC5389] apply to STUN-formatted > messages. This means that all the message-forming and -processing > descriptions in this document are implicitly prefixed with the rules > of [RFC5389]. I found that part of the specification (and STUN) somewhat confusing. For e= xample, we get "even port" specified as: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R| RFFU | +-+-+-+-+-+-+-+-+ While the 8 bit transport type (requested transport) is specified as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | RFFU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Do I understand correctly that the "attribute length" field shall be set to= 1 byte for Even-Port, and to 4 bytes for "requested-transport"? The specif= ication would be clearer, and would prevent potential implementation mistak= es, if the attribute descriptions mentioned explicitly the value of the att= ribute length. If that is so, what is the rationale for the encoding of the requested tran= sport? Why not simply specify: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Protocol | +-+-+-+-+-+-+-+-+ And let the T-L-V encoded do the padding? From huitema@windows.microsoft.com Sun Mar 1 18:34: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 E490028C155 for ; Sun, 1 Mar 2009 18:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9KG-uQVPpqa for ; Sun, 1 Mar 2009 18:34:47 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id B60183A6A86 for ; Sun, 1 Mar 2009 18:34:47 -0800 (PST) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sun, 1 Mar 2009 18:35:06 -0800 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.2.99.4; Sun, 1 Mar 2009 18:35:06 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Sun, 1 Mar 2009 18:37:03 -0800 From: Christian Huitema To: Gonzalo Camarillo , Philip Matthews Date: Sun, 1 Mar 2009 18:35:02 -0800 Thread-Topic: [BEHAVE] Comments on draft-ietf-behave-turn-ipv6-05 Thread-Index: AcmaYpjb5tNBiOsQTKmaVZ3tywUxogAe3FJg Message-ID: <8EFB68EAE061884A8517F2A755E8B60A1CB285332D@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <3D3387E8-1DEE-4405-AEAD-46706406DD92@magma.ca> <49AA6CFE.3080305@ericsson.com> In-Reply-To: <49AA6CFE.3080305@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-behave-turn-ipv6@tools.ietf.org" , Behave WG Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-ipv6-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: Mon, 02 Mar 2009 02:34:49 -0000 > > *) Must a TURN server implementing this draft support > > v4-to-v6/v6-to-v4 relaying? What about v6-to-v6 relaying? Personally, > > I feel that a server should be able to conform to this draft if it > > just supports the REQUESTED-ADDRESS-TYPE attribute and only relays > > v4-to-v4. Whatever decision is made, I think the draft should make a > > definite statement on these points. > > There was another comment on the list on this topic stating that > supporting this extension should imply that the server can handle IPv6 > packets. Once a server can handle IPv6 packets, it is assumed it can > perform the three types of relaying you list above. If there are no good > reasons for a server to support only a subset of them, we do not need to > add any more complexity here. I have added the following text: > > "A TURN server that supports a set of address families is assumed to be > able to relay packets between them. If a server does not support the > address family requested by a client, the server returns a 440 > (Address Family not Supported) error response." I think that the draft confuses relaying and translation. TURN is "a transp= ort relay". The client uses TURN to obtain an address + port pair that will= be reachable by its peers. Packets received by the server on that address = are forwarded to the client, and the client can send packets from that addr= ess. As stated in Philip's original comment, the implementation will be much sim= pler and much less error prone if we specify that "the relayed-transport-ad= dress and all peer transport addresses must use the same address family." That means the TURN server should not engage in explicit packet conversion.= If the client obtained from the server the address "1.2.3.4" and tries to = send a packet through that address to "2001:2::3:4", the SEND request shoul= d fail. If the client needs both IPv4 and IPv6 connectivity from a TURN server, it = should request two separate relay addresses. -- Christian Huitema > > *) I think the draft needs to state the following: a) That the client > > transport address and the server transport address must use the same > > address family; b) That the relayed-transport-address and all peer > > transport addresses must use the same address family; c) That the > > addresses in permissions and channel bindings are of the same family > > as the relayed-transport-address. Actually, points (a) and (b) need > > more words, since the actual address families can differ if a NAT64 > > or NAT46 sits in the path between the client and the server, or the > > server and a peer. What must be true is that the address families as > > seen by the client and as seen by the server must be the same. > > I do not think we need to say anything about a) because from the point > of view of the server and of the client, the address families will > always be the same. > > Statements b) and c) go together. I have specified c), which also covers > b). > > > *) This draft proposes an error code 440 "Address Family not > > supported". But I think this error code needs to be redefined as > > "Requested address family relaying not supported". For example, if a > > server supports only v4-to-v4 and v6-to-v6 relaying, and it receives > > an Allocate request with a REQUESTED-ADDRESS-TYPE attribute > > specifying IPv6 on a IPv4 server address, then the problem is not > > that IPv6 is not supported, but that v4-to-v6 relaying is not > > supported. > > See discussion on this point above. > > > > *) I think this draft needs to define an additional error code: "Peer > > address family mismatch". This error code is returned whenever a > > CreatePermission or ChannelBind request is received with an > > XOR-PEER-ADDRESS attribute whose address family does not match the > > address family of the relayed-transport-address. Similarly, I think > > this draft needs to define what happens when a Send or Data > > indication is received where the XOR-PEER-ADDRESS attribute contains > > an address of the wrong family. > > Done as part of the specification of c) above. > > > > *) This draft defines how a TURN server reacts if a Refresh request > > contains an (unexpected) REQUESTED-ADDRESS-TYPE attribute. This may > > be desirable, but I will note that the base TURN spec says nothing > > similar about all the other attribute of TURN. Furthermore, this > > draft says nothing about an unexpected REQUESTED-ADDRESS-TYPE > > attribute in a CreatePermission, ChannelBind, Send, or Data message. > > So I think the WG needs to decide that either such behavior needs to > > be specified, or that it does not need to be specified, and the two > > drafts updated appropriately. > > You are right that specifications cannot specify every possible error > case. However, they should specify those error cases that appear more > often or that are particularly confusing. I think this error case is one > of them. So, I suggest we leave it as is. > > > *) The draft references the SIIT spec (RFC 2765) for the details of > > how to translate v4-to-v6 and v6-to-v4. However, the base TURN > > specification is carefully written so that a TURN server can be > > implemented by a userland process without special privileges, and > > unfortunately most of the translations specified by SIIT require > > detailed header access of the kind not normally available to an > > un-privileged userland process. In my opinion, we want to preserve > > this property of TURN, and thus this draft should define translations > > that satisfy this constraint. > > Done. > > > *) The above comment also applies to the v6-to-v6 relaying rules > > specified in section 6 of this draft. Some of the v6-to-v6 rules > > specified cannot normally be implemented by an un-privileged userland > > process. For example, un-privileged userland processes cannot > > typically send ICMP messages. > > Done. > > > *) Section 12 of the base TURN spec describes header field processing > > in terms of Preferred and Alternate behaviors. I think that section 6 > > of this draft should do the same. > > > > > > *) Suggestion: rename REQUESTED-ADDRESS-TYPE to > > REQUESTED-ADDRESS-FAMILY. I feel this would make the purpose of the > > attribute clearer. > > Done. > > > From a different email: > > > Two additional comments. > > > > *) If the RESERVATION-TOKEN attribute is present in the Allocate > > request, then I think the REQUESTED-ADDRESS-TYPE attribute must not > > be present, and the address family is determined from the reserved > > transport address. Furthermore, I suggest that we allow the Allocate > > request containing the RESERVATION-TOKEN attribute to arrive over any > > transport (as is done today), including over a different address > > family -- thus it is possible that this subsequent request will > > involve a different form of relaying. (I.e., the first request might > > be v4-to-v4 relaying, while the second is v6-to-v4 relaying). > > Done. > > > *) The draft says: > > > > If the REQUESTED-ADDRESS-TYPE attribute is absent, the server MUST > > allocate an IPv4 transport address to the TURN client. > > > > If the request does not contain a REQUESTED-ADDRESS-TYPE attribute, > > then it is from an client that supports only v4-to-v4 relaying. So I > > am thinking that the server should reject this request if it arrives > > on a v6 server transport address. > > See discussion on this point above. > > Thanks, > > Gonzalo > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From gonzalo.camarillo@ericsson.com Sun Mar 1 23:56: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 3522D3A6BC0 for ; Sun, 1 Mar 2009 23:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.541 X-Spam-Level: X-Spam-Status: No, score=-4.541 tagged_above=-999 required=5 tests=[AWL=1.708, BAYES_00=-2.599, HELO_EQ_SE=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 aZ-kk8m7jqSt for ; Sun, 1 Mar 2009 23:56:22 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4CF973A6BB6 for ; Sun, 1 Mar 2009 23:56:22 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DB7992059B; Mon, 2 Mar 2009 08:56:46 +0100 (CET) X-AuditID: c1b4fb3c-ab005bb000001b43-3a-49ab913ebc36 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BB3112074C; Mon, 2 Mar 2009 08:56:46 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 08:56:45 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 08:56:46 +0100 Message-ID: <49AB913D.1030001@ericsson.com> Date: Mon, 02 Mar 2009 09:56:45 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Christian Huitema References: <3D3387E8-1DEE-4405-AEAD-46706406DD92@magma.ca> <49AA6CFE.3080305@ericsson.com> <8EFB68EAE061884A8517F2A755E8B60A1CB285332D@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1CB285332D@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2009 07:56:46.0215 (UTC) FILETIME=[6F124170:01C99B0C] X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-behave-turn-ipv6@tools.ietf.org" , Behave WG , Philip Matthews Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-ipv6-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: Mon, 02 Mar 2009 07:56:23 -0000 Hi, > As stated in Philip's original comment, the implementation will be > much simpler and much less error prone if we specify that "the > relayed-transport-address and all peer transport addresses must use > the same address family." yes, and I agreed to that in my previous email. We are on the same page. Thanks, Gonzalo From root@core3.amsl.com Wed Mar 4 11: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 13A203A6830; Wed, 4 Mar 2009 11: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: <20090304194502.13A203A6830@core3.amsl.com> Date: Wed, 4 Mar 2009 11:45:02 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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, 04 Mar 2009 19: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 : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations Author(s) : S. Perreault, J. Rosenberg Filename : draft-ietf-behave-turn-tcp-02.txt Pages : 14 Date : 2009-03-04 This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for NAT traversal, to allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the STUN server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-tcp-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-turn-tcp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-04113506.I-D@ietf.org> --NextPart-- From simon.perreault@viagenie.ca Wed Mar 4 11:54: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 8E0D93A6D20 for ; Wed, 4 Mar 2009 11:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.362, 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 hhoETFLtGIeq for ; Wed, 4 Mar 2009 11:54: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 6BA9F3A6D2E for ; Wed, 4 Mar 2009 11:54:44 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id C898B29E1565; Wed, 4 Mar 2009 14:55:12 -0500 (EST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id BA38B29E151D for ; Wed, 4 Mar 2009 14:55:12 -0500 (EST) Message-ID: <49AEDCA0.2070602@viagenie.ca> Date: Wed, 04 Mar 2009 14:55:12 -0500 From: Simon Perreault User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: behave@ietf.org References: <20090304194502.13A203A6830@core3.amsl.com> In-Reply-To: <20090304194502.13A203A6830@core3.amsl.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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, 04 Mar 2009 19:54:45 -0000 Internet-Drafts@ietf.org wrote: > Title : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations > Author(s) : S. Perreault, J. Rosenberg > Filename : draft-ietf-behave-turn-tcp-02.txt > Pages : 14 > Date : 2009-03-04 Changelog: - Defined the mechanisms in detail. Open issues: - Are the use cases compelling? (Will be discussed in SFO.) - How to maintain the NAT bindings for the data connections. Some ideas: - TCP keep-alive - Application protocol must do it. - Do we need a Connect request? ICE wouldn't use it. If we remove Connect, we can also remove Listen because it would be implicit. That would save one round trip. It would also work better with the rest of ICE, which only mentions allocations. Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From petithug@acm.org Wed Mar 4 12: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 AE0D43A6B99 for ; Wed, 4 Mar 2009 12:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jmmN2B-t-8X for ; Wed, 4 Mar 2009 12:38:07 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 42D423A684E for ; Wed, 4 Mar 2009 12:38:01 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 95501DFC51DE; Wed, 4 Mar 2009 20:38:29 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTP id BE5DEDFC51DA; Wed, 4 Mar 2009 20:38:28 +0000 (UTC) Message-ID: <49AEE6C4.6080909@acm.org> Date: Wed, 04 Mar 2009 12:38:28 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Simon Perreault References: <20090304194502.13A203A6830@core3.amsl.com> <49AEDCA0.2070602@viagenie.ca> In-Reply-To: <49AEDCA0.2070602@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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, 04 Mar 2009 20:38:07 -0000 Simon Perreault wrote: > Internet-Drafts@ietf.org wrote: >> Title : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations >> Author(s) : S. Perreault, J. Rosenberg >> Filename : draft-ietf-behave-turn-tcp-02.txt >> Pages : 14 >> Date : 2009-03-04 > > Changelog: > > - Defined the mechanisms in detail. > > Open issues: > > - Are the use cases compelling? (Will be discussed in SFO.) > > - How to maintain the NAT bindings for the data connections. Some ideas: > - TCP keep-alive > - Application protocol must do it. > > - Do we need a Connect request? ICE wouldn't use it. If we remove Connect, we > can also remove Listen because it would be implicit. That would save one round > trip. It would also work better with the rest of ICE, which only mentions > allocations. > One missing open issue is multiple connections vs shared connection (ala SSH). As far as I can read in the minutes of the Minneapolis meeting and the subsequent discussions in the mailing-list, nothing was decided. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From dwing@cisco.com Wed Mar 4 13:57: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 62E2E3A6B6C for ; Wed, 4 Mar 2009 13:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 oc5JwEIZGPTr for ; Wed, 4 Mar 2009 13:57:20 -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 BB1FC3A68DC for ; Wed, 4 Mar 2009 13:57:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,303,1233532800"; d="scan'208";a="150949948" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 04 Mar 2009 21:57:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n24Lvm2t006770; Wed, 4 Mar 2009 13:57:48 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n24LvmEq028716; Wed, 4 Mar 2009 21:57:48 GMT From: "Dan Wing" To: "'Marc Petit-Huguenin'" , "'Simon Perreault'" References: <20090304194502.13A203A6830@core3.amsl.com><49AEDCA0.2070602@viagenie.ca> <49AEE6C4.6080909@acm.org> Date: Wed, 4 Mar 2009 13:57:48 -0800 Message-ID: <0adc01c99d14$41bfded0$c2f0200a@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: <49AEE6C4.6080909@acm.org> Thread-Index: AcmdCUCMz3dd2qrsThW5qyx9ZWsONAACGJPg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1230; t=1236203868; x=1237067868; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20draft-petithuguenin-turn-tcp-variant-00.txt=20[ was=20RE=3A=20[BEHAVE]=20I-D=20Action=3Adraft-ietf-behave-tu rn-tcp-02.txt] |Sender:=20; bh=r7AFG3JEJ3XBa59CM64qEl6qA/4L4+Cvfna4hQWYNLw=; b=P1RtHWsUFYl5XSwuS94vKn19QTXdvNjiWssTur3ya1Uh+xy1k3l7PMyOZf hmUfmZakyTZBFR6sa0+C/c0lB0TVkF7Z4bcvqHjitrwmGsbo2VnkV+pJis/e 7ydNG+sqVIBvgJr4ax0HRZy89dyH5qutBQXbhEe5iO6cs4ch0iNqA=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: behave@ietf.org Subject: [BEHAVE] draft-petithuguenin-turn-tcp-variant-00.txt [was RE: I-D Action:draft-ietf-behave-turn-tcp-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, 04 Mar 2009 21:57:27 -0000 > One missing open issue is multiple connections vs shared connection > (ala SSH). As far as I can read in the minutes of the Minneapolis > meeting and the subsequent discussions in the mailing-list, nothing > was decided. For everyone else's reference, here are pointers to the mailing list discussion of your proposal,=20 draft-petithuguenin-turn-tcp-variant-00.txt: your announcement of the I-D: http://www.ietf.org/mail-archive/web/behave/current/msg04938.html R=E9mi Denis-Courmont's comments: http://www.ietf.org/mail-archive/web/behave/current/msg04942.html Simon Perreault's comments: http://www.ietf.org/mail-archive/web/behave/current/msg04939.html your followup: http://www.ietf.org/mail-archive/web/behave/current/msg04952.html where you wrote: > > Some of your arguments are absolutely true (HOLB), some are=20 > debatable, and the others I have to think about them. > > But there is also some advantages to the single connection=20 > solution, for example establishing a new peer TCP connection is=20 > faster. Please also have a look to section 3.3.2 in the excellent=20 > draft-iab-ip-model-evolution. > Please followup to Remi's comments in this thread. -d From petithug@acm.org Wed Mar 4 14:24: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 313B03A6CBE for ; Wed, 4 Mar 2009 14:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27fFCVa8hd2y for ; Wed, 4 Mar 2009 14:24:23 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 81AA13A6CAB for ; Wed, 4 Mar 2009 14:24:23 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 5A344DFC51DE; Wed, 4 Mar 2009 22:24:52 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTP id 21CC6DFC51DA; Wed, 4 Mar 2009 22:24:51 +0000 (UTC) Message-ID: <49AEFFB2.1030207@acm.org> Date: Wed, 04 Mar 2009 14:24:50 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Dan Wing References: <20090304194502.13A203A6830@core3.amsl.com><49AEDCA0.2070602@viagenie.ca> <49AEE6C4.6080909@acm.org> <0adc01c99d14$41bfded0$c2f0200a@cisco.com> In-Reply-To: <0adc01c99d14$41bfded0$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] draft-petithuguenin-turn-tcp-variant-00.txt [was RE: I-D Action:draft-ietf-behave-turn-tcp-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, 04 Mar 2009 22:24:24 -0000 Dan Wing wrote: >> One missing open issue is multiple connections vs shared connection >> (ala SSH). As far as I can read in the minutes of the Minneapolis >> meeting and the subsequent discussions in the mailing-list, nothing >> was decided. > > For everyone else's reference, here are pointers to the mailing list > discussion of your proposal, > draft-petithuguenin-turn-tcp-variant-00.txt: > > your announcement of the I-D: > http://www.ietf.org/mail-archive/web/behave/current/msg04938.html > > Rémi Denis-Courmont's comments: > http://www.ietf.org/mail-archive/web/behave/current/msg04942.html > > Simon Perreault's comments: > http://www.ietf.org/mail-archive/web/behave/current/msg04939.html > > your followup: > http://www.ietf.org/mail-archive/web/behave/current/msg04952.html > where you wrote: > > > > > Some of your arguments are absolutely true (HOLB), some are > > debatable, and the others I have to think about them. > > > > But there is also some advantages to the single connection > > solution, for example establishing a new peer TCP connection is > > faster. Please also have a look to section 3.3.2 in the excellent > > draft-iab-ip-model-evolution. > > > > Please followup to Remi's comments in this thread. > Thanks. I will answer the remaining points in Remi's comments and publish a new version of the I-D before the deadline. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From dwing@cisco.com Wed Mar 4 16:10: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 BF72F3A69D5 for ; Wed, 4 Mar 2009 16:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 gcjx3qTQ3Clz for ; Wed, 4 Mar 2009 16:10:54 -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 788803A68D1 for ; Wed, 4 Mar 2009 16:10:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,304,1233532800"; d="scan'208";a="137870405" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 05 Mar 2009 00:11:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n250BNo1029429 for ; Wed, 4 Mar 2009 16:11:23 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n250BNp5021696 for ; Thu, 5 Mar 2009 00:11:23 GMT From: "Dan Wing" To: Date: Wed, 4 Mar 2009 16:11:23 -0800 Message-ID: <0bc201c99d26$eb2442b0$c2f0200a@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: AcmdGOJnsZlQBkDlR9CMw4B5JKJgqgADU7JA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1734; t=1236211883; x=1237075883; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20draft-wing-behave-nat64-referrals-00 |Sender:=20; bh=NnodhGf8X5OYnhVtBafwLx2zL8GVLlb2euHxXpPH3ws=; b=d5RcImShb8MAq3mRK7bxqEmhH8UbWyrJa3BY4esIY8mBJwMOWy6OtwJlQi 4ZdVkS6lRYkRrZKX/YhKkaPGhPlTKuZYYZhRBROzrRwg7uh4vra0RbSEFWGo RHMjTtYwkb; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [BEHAVE] draft-wing-behave-nat64-referrals-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, 05 Mar 2009 00:10:55 -0000 This document discusses how SIP and BitTorrent perform referrals between IP address families. A quick summary of the document: An IPv6-only SIP endpoint can use a NAT64 or a TURN-IPv6 server to communicate with an IPv4-only SIP endpoint. When the IPv6-only SIP endpoint wants to refer the IPv4-only SIP endpoint to another host, it refers the IPv4 address. By referring the IPv4 address, referalls are successful to IPv4-only hosts, to dual-stack hosts, and IPv6-only hosts (if those IPv6-only hosts have a NAT64). In all cases that are expected to work, such IPv4 referalls work. BitTorrent clients do not handle referrals across a NAT64, and will require upgrades to work across a NAT64. -d -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, March 04, 2009 2:30 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-wing-behave-nat64-referrals-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Referrals Across a NAT64 Author(s) : D. Wing Filename : draft-wing-behave-nat64-referrals-00.txt Pages : 11 Date : 2009-03-04 This document describes several scenarios where an IP address is referred across a NAT64 translator. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wing-behave-nat64-referrals-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. From hvn@archred.com Wed Mar 4 07:53: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 C4F1B3A6837 for ; Wed, 4 Mar 2009 07:53:11 -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 DGUlgFya+Rov for ; Wed, 4 Mar 2009 07:53:11 -0800 (PST) Received: from mail.archred.com (mail.archred.com [195.197.255.19]) by core3.amsl.com (Postfix) with ESMTP id CFB4C28C39B for ; Wed, 4 Mar 2009 07:52:56 -0800 (PST) Received: from [172.20.3.142] (unknown [172.20.3.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.archred.com (Postfix) with ESMTP id 4C34F2A9BC for ; Wed, 4 Mar 2009 17:53:23 +0200 (EET) Message-ID: <49AEA3EF.9010104@archred.com> Date: Wed, 04 Mar 2009 17:53:19 +0200 From: Heikki Vatiainen User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 05 Mar 2009 08:07:44 -0800 Subject: [BEHAVE] Small typo in draft-ietf-behave-turn-13 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2009 16:08:51 -0000 While going through the TURN draft, I noticed a small typo in the "Detailed example" section, page 51. XOR-PEER-ADDRESS has been written twice as XOR-PEER-ADDRSSS in one of the message sequence charts. -- Heikki Vatiainen Arch Red Oy, Tampere, Finland From dwcraig@qualcomm.com Thu Mar 5 09:50: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 D7BF53A6979 for ; Thu, 5 Mar 2009 09:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjfJXRRWC9yF for ; Thu, 5 Mar 2009 09:50:30 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 50BA23A6879 for ; Thu, 5 Mar 2009 09:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=dwcraig@qualcomm.com; q=dns/txt; s=qcdkim; t=1236275460; x=1267811460; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Craig,=20Dave"=20|To:=20S imon=20Perreault=20,=0D=0A =20=20=20=20=20=20=20=20"behave@ietf.org"=0D=0A=09|Date:=20Thu,=205=20Mar=202009=2009:50:53=20-08 00|Subject:=20RE:=20[BEHAVE]=20I-D=20Action:draft-ietf-be have-turn-tcp-02.txt|Thread-Topic:=20[BEHAVE]=20I-D=20Act ion:draft-ietf-behave-turn-tcp-02.txt|Thread-Index:=20Acm dAyVVoFTXuu+oTfiQRD/HHGLLoQAt6kxg|Message-ID:=20|References:=20<20090304194502.13A203A6830@core3.am sl.com>=0D=0A=20<49AEDCA0.2070602@viagenie.ca> |In-Reply-To:=20<49AEDCA0.2070602@viagenie.ca> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5544"=3B=20a=3D"15996876"; bh=y98KqLIDLL5EW9gH3/qZJ9Zdo25hhFFuNdV5IlEKX3c=; b=RqsslPO17xAE1EezBoyoYX72F4hRIybOJlwLUlxmKN0Ec1rHco5ovv9T 2zyBudbukqAtKhvQsVic2zrvaUKlMkQAJWRermTjFkMFmrlpRRfJXApNw wr8F/0c4XK5/Q8cHxED9YpxZbzJw4b1xnDazmehnq3wz3KYRo1E/OU8gq g=; X-IronPort-AV: E=McAfee;i="5300,2777,5544"; a="15996876" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2009 09:50:59 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n25Hox50010133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Mar 2009 09:50:59 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n25HouvH022309 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Mar 2009 09:50:58 -0800 (PST) Received: from NASANEXMB03.na.qualcomm.com ([10.45.76.135]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Thu, 5 Mar 2009 09:50:56 -0800 From: "Craig, Dave" To: Simon Perreault , "behave@ietf.org" Date: Thu, 5 Mar 2009 09:50:53 -0800 Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-02.txt Thread-Index: AcmdAyVVoFTXuu+oTfiQRD/HHGLLoQAt6kxg Message-ID: References: <20090304194502.13A203A6830@core3.amsl.com> <49AEDCA0.2070602@viagenie.ca> In-Reply-To: <49AEDCA0.2070602@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Thu, 05 Mar 2009 17:50:32 -0000 > - How to maintain the NAT bindings for the data connections. Some ideas: > - TCP keep-alive > - Application protocol must do it. How about requiring a means for the application to query the=20 keep-alive interval and then disabling TCP keep alive? Applications=20 running on energy-efficient devices can couple their keep alive=20 messages with the required refresh. When they need to conserve more=20 energy they can scale back the refresh frequency at the risk of=20 breaking and having to reestablish the connection. Otherwise, applications scaling back their keep alive messages will=20 not result in an energy consumption savings. Their first hop link=20 will periodically have to turn on to send the RFC 1122 TCP keep-alive=20 or the keep-alive specified draft-ietf-mmusic-ice-19#section-10 when=20 there is no data send. Thanks, Dave From simon.perreault@viagenie.ca Thu Mar 5 09:55: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 BA40528C3C7 for ; Thu, 5 Mar 2009 09:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.278, 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 zZLpww6uaNoU for ; Thu, 5 Mar 2009 09:55:42 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 79A4328C288 for ; Thu, 5 Mar 2009 09:55:37 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id DB75C29E1580; Thu, 5 Mar 2009 12:56:06 -0500 (EST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id BFC5D29E14E0; Thu, 5 Mar 2009 12:56:06 -0500 (EST) Message-ID: <49B01236.8070101@viagenie.ca> Date: Thu, 05 Mar 2009 12:56:06 -0500 From: Simon Perreault User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Craig, Dave" References: <20090304194502.13A203A6830@core3.amsl.com> <49AEDCA0.2070602@viagenie.ca> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Thu, 05 Mar 2009 17:55:42 -0000 Craig, Dave wrote: > How about requiring a means for the application to query the > keep-alive interval and then disabling TCP keep alive? By asking the NAT device? If so, I fear this is out of scope for TURN-TCP. By measuring it? I may be long (5 days by default on Linux) so measuring it will also be long. Not practical. Not sure we're on the same wavelength... Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dwcraig@qualcomm.com Thu Mar 5 10:05: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 E29D628C494 for ; Thu, 5 Mar 2009 10:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0T+KjoM0PFUt for ; Thu, 5 Mar 2009 10:05:15 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id DE8ED28C40B for ; Thu, 5 Mar 2009 10:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=dwcraig@qualcomm.com; q=dns/txt; s=qcdkim; t=1236276345; x=1267812345; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Craig,=20Dave"=20|To:=20S imon=20Perreault=20|CC:=20"b ehave@ietf.org"=20|Date:=20Thu,=205=20Ma r=202009=2010:05:41=20-0800|Subject:=20RE:=20[BEHAVE]=20I -D=20Action:draft-ietf-behave-turn-tcp-02.txt |Thread-Topic:=20[BEHAVE]=20I-D=20Action:draft-ietf-behav e-turn-tcp-02.txt|Thread-Index:=20Acmdu65YL4jrpNWEQhqmSSY QKeqZ8QAAEOTA|Message-ID:=20|References: =20<20090304194502.13A203A6830@core3.amsl.com>=0D=0A=09<4 9AEDCA0.2070602@viagenie.ca>=0D=0A=09=0D =0A=20<49B01236.8070101@viagenie.ca>|In-Reply-To:=20<49B0 1236.8070101@viagenie.ca>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5544"=3B=20a=3D"15997541"; bh=Zag6HHM679eq0eV3cjX0DR8sWR18FnkaUSrpt5jNnGI=; b=jjhd7jPyOkU60+N3rH9HAsGuf2MM1yHw8FNaub/6CC+uArVU/zIccdSk 11W1J4/KPvHVE7lr06XNPvqXsp0lP4qKoIsiHYcCD+xoxSs/f4eshVvke NbGvWon5glvprvP5BBqiRj/dbxQpwPVlmcpoiYFVkUqDlaWVkJegAFapZ w=; X-IronPort-AV: E=McAfee;i="5300,2777,5544"; a="15997541" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2009 10:05:45 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n25I5iNY012913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Mar 2009 10:05:45 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n25I5eRK026031 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Mar 2009 10:05:44 -0800 (PST) Received: from NASANEXMB03.na.qualcomm.com ([10.45.76.135]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Thu, 5 Mar 2009 10:05:43 -0800 From: "Craig, Dave" To: Simon Perreault Date: Thu, 5 Mar 2009 10:05:41 -0800 Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-02.txt Thread-Index: Acmdu65YL4jrpNWEQhqmSSYQKeqZ8QAAEOTA Message-ID: References: <20090304194502.13A203A6830@core3.amsl.com> <49AEDCA0.2070602@viagenie.ca> <49B01236.8070101@viagenie.ca> In-Reply-To: <49B01236.8070101@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] I-D Action:draft-ietf-behave-turn-tcp-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: Thu, 05 Mar 2009 18:05:17 -0000 Craig, Dave wrote: > How about requiring a means for the application to query the=20 > keep-alive interval and then disabling TCP keep alive? Simon Perreault wrote: > By asking the NAT device? If so, I fear this is out of scope for TURN-TCP= . Yes, that and measurement are not tractable solutions. I was referring to = querying the configured refresh interval inside the client. That way there= are not a lot of application-specific refresh intervals to configure when = you find out that a particular NAT you traverse removes bindings quickly. It also gives the application the control reduce traffic when needing to co= nserve energy. Dave -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Simon Perreault Sent: Thursday, March 05, 2009 9:56 AM To: Craig, Dave Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-02.txt Craig, Dave wrote: > How about requiring a means for the application to query the=20 > keep-alive interval and then disabling TCP keep alive? By asking the NAT device? If so, I fear this is out of scope for TURN-TCP. By measuring it? I may be long (5 days by default on Linux) so measuring it= will also be long. Not practical. Not sure we're on the same wavelength... Simon --=20 STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.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 Mar 5 18:33: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 9E8553A693C for ; Thu, 5 Mar 2009 18:33:05 -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 xY-VMdTBqIam for ; Thu, 5 Mar 2009 18:33:04 -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 9B9363A689F for ; Thu, 5 Mar 2009 18:33:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,311,1233532800"; d="scan'208";a="262297110" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Mar 2009 02:33:34 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n262XYvV030175 for ; Thu, 5 Mar 2009 18:33:34 -0800 Received: from dwingwxp01 (dhcp-171-70-247-3.cisco.com [171.70.247.3]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n262XYkM019626 for ; Fri, 6 Mar 2009 02:33:34 GMT From: "Dan Wing" To: Date: Thu, 5 Mar 2009 18:33:34 -0800 Message-ID: <111001c99e03$f2622aa0$c2f0200a@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: AcmeA/I3QiIA1IPXSf+rPMlBwoT9Xw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1856; t=1236306814; x=1237170814; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20preliminary=20agenda=20for=20San=20Francisco |Sender:=20; bh=Sqj3HX1Re8WHloaKlTCKnN4v0D40qCRGP5RiKtLJROg=; b=VDaTxhtb29+ld0QeYb/SarxT/UxNwPU1D0LsA95d/iy9eVRpgob4ydMXkc l+bKOWRs2t2l+VBx/YgdMQRsT0k0NxoTobpc0LO9zDHjeSF6L+vqfZnKT17W OyW81cSCXX; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [BEHAVE] preliminary agenda for San Francisco X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 06 Mar 2009 02:33:05 -0000 BEHAVE's preliminary agenda has been posted at http://www.ietf.org/proceedings/09mar/agenda/behave.html -d ----- SESSION ONE TUESDAY, March 24, 9:00-11:30 9:00 Note takers, agenda, milestones (Chairs, 10) 9:10 Prioritize Translation Scenarios, New Milestones (Chairs, 30) 9:40 Framework (Fred Baker, 25?) draft-baker-behave-v4v6-framework 10:05 Translation (Xing Li, 25?) draft-baker-behave-v4v6-translation 10:30 NAT64 (Marcelo Bagnulo Braun, 25?) draft-bagnulo-behave-nat64 10:55 DNS64 (Marcelo Bagnulo Braun, 25?) draft-bagnulo-behave-dns64 11:20 end SESSION TWO WEDNESDAY, March 25, 9:00-11:30 9:00 Agenda, note takers (Chairs, 5) 9:05 IPv6 destination header option for IPv4 (Remi Denis-Courmont, 10) translator mapping notification draft-denis-behave-v4v6exthdr 9:15 Source IP NAT (Charles Perkins, 10) draft-perkins-sourceipnat 9:25 Subscriber-aware NAT44 (David Miles, 15) draft-miles-behave-l2nat 9:40 TURN-TCP (Simon Perreault, 15+) draft-ietf-behave-turn-tcp 9:55 TURN (Philip Matthews, 10?) draft-ietf-behave-turn 10:05 multicast v4/v6 translation (Stig Venaas, 15+) draft-venaas-behave-mcast46 10:20 end (agenda version: 0.41/March 3) From mohamed.boucadair@orange-ftgroup.com Fri Mar 6 06:53: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 782793A680B; Fri, 6 Mar 2009 06:53:32 -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, HELO_EQ_FR=0.35, 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 H-xHyPmU9Rly; Fri, 6 Mar 2009 06:53:31 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 0B8133A6803; Fri, 6 Mar 2009 06:53:30 -0800 (PST) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 15:54:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C99E6B.621841D0" Date: Fri, 6 Mar 2009 15:53:59 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007D4ECFA@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-boucadair-behave-ipv6-portrange-01.txt Thread-Index: AcmeaoFRnNaBbeL2T3iQrexrHfgHiwAALoYQ From: To: , X-OriginalArrivalTime: 06 Mar 2009 14:54:02.0449 (UTC) FILETIME=[637B6410:01C99E6B] Subject: [BEHAVE] TR: I-D Action:draft-boucadair-behave-ipv6-portrange-01.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, 06 Mar 2009 14:53:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99E6B.621841D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Dear all, A new version of the draft has been submitted. Comments are more than welcome. Cheers Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = Internet-Drafts@ietf.org Envoy=E9 : vendredi 6 mars 2009 15:45 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-behave-ipv6-portrange-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Flexible IPv6 Migration Scenarios in the Context of = IPv4 Address Shortage Author(s) : M. Boucadair, et al. Filename : draft-boucadair-behave-ipv6-portrange-01.txt Pages : 47 Date : 2009-03-06 This memo presents a solution to solve IPv4 address shortage and ease IPv4-IPv6 interworking. The document presents a set of incremental = steps for the deployment of IPv6 as a means to solve IPv4 address = exhaustion. Stateless IPv4/IPv6 address mapping functions are = introduced and IPv4-IPv6 interconnection scenarios presented. This memo = advocates for a more proactive approach for the deployment of IPv6 into operational networks. This document provides both the specification of the solution and = deployment scenarios together with migrations paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-behave-ipv6-portrange= -01.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_001_01C99E6B.621841D0 Content-Type: application/octet-stream; name="draft-boucadair-behave-ipv6-portrange-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-boucadair-behave-ipv6-portrange-01.URL Content-Disposition: attachment; filename="draft-boucadair-behave-ipv6-portrange-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItYmVoYXZlLWlwdjYtcG9ydHJhbmdlLTAxLnR4dA0K ------_=_NextPart_001_01C99E6B.621841D0-- From marcelo@it.uc3m.es Sat Mar 7 10:51: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 E506D3A6B59 for ; Sat, 7 Mar 2009 10:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 h2fuoaefX1Ic for ; Sat, 7 Mar 2009 10:51:24 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id BB02D3A6B68 for ; Sat, 7 Mar 2009 10:51:24 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (81.pool85-53-139.dynamic.orange.es [85.53.139.81]) by smtp01.uc3m.es (Postfix) with ESMTP id A0BADB4D66A for ; Sat, 7 Mar 2009 19:51:54 +0100 (CET) Message-ID: <49B2C24A.7020605@it.uc3m.es> Date: Sat, 07 Mar 2009 19:51:54 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Behave WG Content-Type: multipart/mixed; boundary="------------050800000009050307000106" Subject: [BEHAVE] [Fwd: I-D Action:draft-bagnulo-behave-dns64-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: Sat, 07 Mar 2009 18:51:26 -0000 This is a multi-part message in MIME format. --------------050800000009050307000106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We posted a new version of dns64 This version tries to reflect the feedback we got from the dns community, especially in the DNSSEC part feedback is welcome -------- Mensaje original -------- Asunto: I-D Action:draft-bagnulo-behave-dns64-02.txt Fecha: Sat, 7 Mar 2009 10:45:01 -0800 (PST) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-bagnulo-behave-dns64-02.txt Pages : 27 Date : 2009-03-07 DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with NAT64, 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 NAT64. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bagnulo-behave-dns64-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. --------------050800000009050307000106 Content-Type: Message/External-body; name="draft-bagnulo-behave-dns64-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-bagnulo-behave-dns64-02.txt" Content-Type: text/plain Content-ID: <2009-03-07103756.I-D@ietf.org> --------------050800000009050307000106 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 --------------050800000009050307000106-- From marcelo@it.uc3m.es Sat Mar 7 11:41: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 A92DE28C1C0 for ; Sat, 7 Mar 2009 11:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 g0pwFsGMoXHX for ; Sat, 7 Mar 2009 11:41:21 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5C7383A6B25 for ; Sat, 7 Mar 2009 11:41:20 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (81.pool85-53-139.dynamic.orange.es [85.53.139.81]) by smtp01.uc3m.es (Postfix) with ESMTP id D38EFB4937C for ; Sat, 7 Mar 2009 20:41:48 +0100 (CET) Message-ID: <49B2CDF8.1060701@it.uc3m.es> Date: Sat, 07 Mar 2009 20:41:44 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16506.001 Subject: [BEHAVE] [Fwd: Re: nat64-02 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: Sat, 07 Mar 2009 19:41:22 -0000 Hi Reinaldo, thanks for your review some replies below... Reinaldo Penno escribió: > Hello, > > I've been going through nat64 and have a few comments/questions: > > 1) > > " 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 > (Pref64:X,x), where y and x are ports chosen by H2." > > How can H2 (the destination) choose the source port of both the packets used > by the v6 host and the NAT64 on the IPv4 interface? Should it say H1? > yes, fixed > There are also recommendations on RFC4787 about how ports should be mapped > from internal to external networks. I'm assuming those should apply also to > NAT64. > > Yes, this is considered in the normative part of the spec. this is a walkthrough to allow the reader to get familiar with the overall behaviour, the specification itself is later on the doc. > > 2) > > " * The NAT64 includes (Y',y) as source transport address in the > packet and (Pref64:X,x) as destination 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." > > Maybe you mean (Y', y) as the destination and (Pref64:X, x) as the source? > right, fixed > 3) > " If a NAT64 filters on its IPv4 interface, then an incoming packet is > dropped unless a packet has been recently sent out the interface with > a destination IP address equal to the source IP address of the > incoming packet." > > Maybe substitute this wording by "address-dependent filtering according to > RFC4787". > done > Below you say " NAT64 filtering is consistent with the recommendations of > RFC 4787.", but RFC4787 REQ-8 allows filtering depending on what is > important for the NAT device: security vs. application transparency. > > Is the reason for address-dependent filtering security? > > mmm, the text says that the NAT64 MAY do filtering, which is equivalent to what you say about the tradeoff between security and transparency, isn't it? > 4) > > " NOTE: The transport protocol is always one of TCP or UDP, even if > the IP packet contains an ICMP message." > > I'm assuming per your TBD this will go away when the draft has ICMP Query > support? > right, ICMP packets will need to be supported as well > 5) > " 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." > > Can you cite the reference for using for the time of at least 10 seconds as > a "MUST"? > > why do we need a reference? We are defining the behaviour in this document, right? But, do you think 10 secs is not approapriate? would you use a different value? which one and why? > 6) > > " 1. If the packet arrived on the IPv4 interface and 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 equal to the source IPv4 address > in the incoming 5-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 SHOULD 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 general I find this section and similar ones very implementation > specific, but regardless I have one comment. > > I think you mean > > "... searches for a session table > entry with a source IPv4 address equal to the destination IPv4 > address in the incoming 5-tuple", > > otherwise they will never match since the source IP address used by the > NAT64 device will always be different from the source v4 address used by > external hosts. > > So, you try to match the destination IPv4 address of a possibly unsolicited > packet with a v4 session that already exists in the session table the > opposite direction, right? This seems consistent with step 2. > > that's what would be needed to actually be able to forward the packet, i.e. if a mapping exists but here we are talking about how to perform filtering. So the text on the draft you mention above is wrong, but i think it should read: it searches for a session table entry with a destination IPv4 address equal to the source IPv4 address in the incoming 5-tuple. would that make more sense to you? > 7) > > " 3. 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." > > This seems to be at odds with REQ-5, REQ-5c of RFC4787 > > You use the word "maximum", but those requirements use " c) A default > value of five minutes or more for the NAT UDP mapping > timer is RECOMMENDED." > > In other words 5 minutes or more is rather different than a maximum of 5 > minutes. > > Maybe you can reference REQ-5c here. > > > right this is one open question whether we will be able to afford endpoint independent mappings for all ports in the scenario of ipv4 depletion we will need to solve this question, so for now we leave the possibility open in the draft what is your opinion on this? Thanks, marcelo > Thanks, > > Reinaldo > > > > > > > > > From marcelo@it.uc3m.es Sat Mar 7 12:19: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 54FFE28C17F for ; Sat, 7 Mar 2009 12:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 sITEIk-A+GVd for ; Sat, 7 Mar 2009 12:19:46 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A87483A6A36 for ; Sat, 7 Mar 2009 12:19:45 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (81.pool85-53-139.dynamic.orange.es [85.53.139.81]) by smtp02.uc3m.es (Postfix) with ESMTP id B05B965ABD2; Sat, 7 Mar 2009 21:03:16 +0100 (CET) Message-ID: <49B2D302.7060802@it.uc3m.es> Date: Sat, 07 Mar 2009 21:03:14 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) 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-5.6.0.1016-16506.002 Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on nat64-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: Sat, 07 Mar 2009 20:19:47 -0000 Reinaldo Penno escribió: > A few more comments as I go through: > > 7) > > " So, NAT64 implements by definition, at least, > endpoint independent filtering, meaning that in order to enable any > packet to flow from the IPv4 side to the IPv6 side, , there must have > been a packet flowing from the IPv6 side to the IPv4 side the created > the binding information to be used for packets in the other > direction." > > I do not think one follows from the other as stated. Sending a packet from > ipv6 to ipv4 only creates the binding. It does not enable packets to flow > from ipv4 to ipv6. right but that would be address dependent mapping right? what is being stated is about endpoint independent filtering > The mapping strategy might be different from the > filtering strategy. > > I think (maybe I'm wrong) that the intent on RFC487 in separating mapping > from filtering was to make these orthogonal issues and allow security to > override things if needed. > > 8) > > " So, NAT64 implements by definition, at least, > endpoint independent filtering, meaning that in order to enable any > packet to flow from the IPv4 side to the IPv6 side," > > You mention endpoint independent but in section "1.2.3. Filtering" what > you seem to describe is address-dependent filtering. > > No, what the text means is that: by its own nature, the nat64 does endpoint independent filtering (Cause there is no mapping to the traffic initiated through the IPv4 interface) The NAt64 can in adition do address depednent filtering, if security considerations deem it necesary > 9) > > " It is possible to configure the NAT64 to implement more > stringent security policy, if endpoint independent mapping is > considered not secure enough" > > I think you mean "endpoint independent filtering" as opposed to endpoint > independent mapping. > > > right Thanks, marcelo > Thanks, > > Reinaldo > > > > > > On 2/26/09 3:03 PM, "Reinaldo Penno" wrote: > > >> Hello, >> >> I've been going through nat64 and have a few comments/questions: >> >> 1) >> >> " 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 >> (Pref64:X,x), where y and x are ports chosen by H2." >> >> How can H2 (the destination) choose the source port of both the packets used >> by the v6 host and the NAT64 on the IPv4 interface? Should it say H1? >> >> There are also recommendations on RFC4787 about how ports should be mapped >> from internal to external networks. I'm assuming those should apply also to >> NAT64. >> >> >> 2) >> >> " * The NAT64 includes (Y',y) as source transport address in the >> packet and (Pref64:X,x) as destination 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." >> >> Maybe you mean (Y', y) as the destination and (Pref64:X, x) as the source? >> >> 3) >> " If a NAT64 filters on its IPv4 interface, then an incoming packet is >> dropped unless a packet has been recently sent out the interface with >> a destination IP address equal to the source IP address of the >> incoming packet." >> >> Maybe substitute this wording by "address-dependent filtering according to >> RFC4787". >> >> Below you say " NAT64 filtering is consistent with the recommendations of >> RFC 4787.", but RFC4787 REQ-8 allows filtering depending on what is >> important for the NAT device: security vs. application transparency. >> >> Is the reason for address-dependent filtering security? >> >> >> 4) >> >> " NOTE: The transport protocol is always one of TCP or UDP, even if >> the IP packet contains an ICMP message." >> >> I'm assuming per your TBD this will go away when the draft has ICMP Query >> support? >> >> 5) >> " 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." >> >> Can you cite the reference for using for the time of at least 10 seconds as >> a "MUST"? >> >> 6) >> >> " 1. If the packet arrived on the IPv4 interface and 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 equal to the source IPv4 address >> in the incoming 5-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 SHOULD 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 general I find this section and similar ones very implementation >> specific, but regardless I have one comment. >> >> I think you mean >> >> "... searches for a session table >> entry with a source IPv4 address equal to the destination IPv4 >> address in the incoming 5-tuple", >> >> otherwise they will never match since the source IP address used by the >> NAT64 device will always be different from the source v4 address used by >> external hosts. >> >> So, you try to match the destination IPv4 address of a possibly unsolicited >> packet with a v4 session that already exists in the session table the >> opposite direction, right? This seems consistent with step 2. >> >> 7) >> >> " 3. 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." >> >> This seems to be at odds with REQ-5, REQ-5c of RFC4787 >> >> You use the word "maximum", but those requirements use " c) A default >> value of five minutes or more for the NAT UDP mapping >> timer is RECOMMENDED." >> >> In other words 5 minutes or more is rather different than a maximum of 5 >> minutes. >> >> Maybe you can reference REQ-5c here. >> >> >> Thanks, >> >> Reinaldo >> >> >> >> >> >> >> >> ------ End of Forwarded Message >> >> _______________________________________________ >> 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 Sat Mar 7 12:34: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 C818528C0E2 for ; Sat, 7 Mar 2009 12:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.323 X-Spam-Level: X-Spam-Status: No, score=-6.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 5PP1B4WE6AOL for ; Sat, 7 Mar 2009 12:34:29 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id AEB8C3A691D for ; Sat, 7 Mar 2009 12:34:28 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (81.pool85-53-139.dynamic.orange.es [85.53.139.81]) by smtp01.uc3m.es (Postfix) with ESMTP id E963AB4E0A1 for ; Sat, 7 Mar 2009 21:34:57 +0100 (CET) Message-ID: <49B2DA71.50306@it.uc3m.es> Date: Sat, 07 Mar 2009 21:34:57 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Behave WG Content-Type: multipart/mixed; boundary="------------040601010007090605050502" Subject: [BEHAVE] [Fwd: I-D Action:draft-bagnulo-behave-nat64-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, 07 Mar 2009 20:34:29 -0000 This is a multi-part message in MIME format. --------------040601010007090605050502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit we have submitted a new versio of the draft, addressing the comments received so far comments are welcome, regards, marcelo -------- Mensaje original -------- Asunto: I-D Action:draft-bagnulo-behave-nat64-03.txt Fecha: Sat, 7 Mar 2009 12:15:01 -0800 (PST) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-bagnulo-behave-nat64-03.txt Pages : 26 Date : 2009-03-07 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. This document specifies NAT64, and gives suggestions on how they should be deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bagnulo-behave-nat64-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. --------------040601010007090605050502 Content-Type: Message/External-body; name="draft-bagnulo-behave-nat64-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-bagnulo-behave-nat64-03.txt" Content-Type: text/plain Content-ID: <2009-03-07120658.I-D@ietf.org> --------------040601010007090605050502 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 --------------040601010007090605050502-- From root@core3.amsl.com Sat Mar 7 15: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 655363A6AA8; Sat, 7 Mar 2009 15: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: <20090307233001.655363A6AA8@core3.amsl.com> Date: Sat, 7 Mar 2009 15:30:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-uri-01.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, 07 Mar 2009 23:30: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 : Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers Author(s) : M. Petit-Huguenin Filename : draft-ietf-behave-turn-uri-01.txt Pages : 12 Date : 2009-03-07 This document defines two URI schemes and the resolution mechanism to convert these URIs to a list of server transport addresses that can be used between a Traversal Using Relays around NAT (TURN) client and server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-uri-01.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-uri-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-07151743.I-D@ietf.org> --NextPart-- From petithug@acm.org Sat Mar 7 15:40: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 1698F3A6AA8 for ; Sat, 7 Mar 2009 15:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymoKDVp3iDLK for ; Sat, 7 Mar 2009 15:40:55 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 6A7C33A67D6 for ; Sat, 7 Mar 2009 15:40:55 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 5FE86DBD40CC; Sat, 7 Mar 2009 23:41:27 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTP id B4E83DBD40C8 for ; Sat, 7 Mar 2009 23:41:26 +0000 (UTC) Message-ID: <49B30626.1070801@acm.org> Date: Sat, 07 Mar 2009 15:41:26 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: behave@ietf.org References: <20090307233001.655363A6AA8@core3.amsl.com> In-Reply-To: <20090307233001.655363A6AA8@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-uri-01.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, 07 Mar 2009 23:40:56 -0000 This new version just fixes one small imprecision discovered when working on a new reference implementation. The draft could use more feedback and if someone wants to implement TURN URI, I will be more than happy to provide my reference implementation and a set of NAPTR and SRV RR that I am developing to help the testing. Also draft-wood-tae-specifying-uri-transports proposes a different way to specify the transport parameter in an URI. I would be happy to discuss if and how this can be applied to a TURN URI. Changelog: o Fixed the contact email. o Changed the IPR to trust200902. o Added case for transport defined but unknown. o Moved RFC 3958 to Normative References. o Added study of [I-D.wood-tae-specifying-uri-transports] in TODO list. 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 : Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers > Author(s) : M. Petit-Huguenin > Filename : draft-ietf-behave-turn-uri-01.txt > Pages : 12 > Date : 2009-03-07 > > This document defines two URI schemes and the resolution mechanism to > convert these URIs to a list of server transport addresses that can > be used between a Traversal Using Relays around NAT (TURN) client and > server. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-uri-01.txt > -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From petithug@acm.org Sat Mar 7 19:45: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 8F3B53A6A95 for ; Sat, 7 Mar 2009 19:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.208 X-Spam-Level: X-Spam-Status: No, score=-102.208 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-AzOxpfEaC5 for ; Sat, 7 Mar 2009 19:45:14 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id B2C543A6A12 for ; Sat, 7 Mar 2009 19:45:14 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 17D17DBD40CC; Sun, 8 Mar 2009 03:45:47 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTP id 5776ADBD40C8 for ; Sun, 8 Mar 2009 03:45:46 +0000 (UTC) Message-ID: <49B33F69.7070907@acm.org> Date: Sat, 07 Mar 2009 19:45:45 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: behave@ietf.org References: <20090304194502.13A203A6830@core3.amsl.com> In-Reply-To: <20090304194502.13A203A6830@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Sun, 08 Mar 2009 03:45:15 -0000 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 : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations > Author(s) : S. Perreault, J. Rosenberg > Filename : draft-ietf-behave-turn-tcp-02.txt > Pages : 14 > Date : 2009-03-04 > > This specification defines an extension of Traversal Using Relays > around NAT (TURN), a relay protocol for NAT traversal, to allows a > TURN client to request TCP allocations, and defines new requests and > indications for the TURN server to open and accept TCP connections > with the client's peers. TURN and this extension both purposefully > restrict the ways in which the relayed address can be used. In > particular, it prevents users from running general purpose servers > from ports obtained from the STUN server. Some comments and questions: - Section 4.3, 4th paragraph: "Once a Listen success response has been received, further Connect or Listen requests for the same allocation MUST NOT be sent." If I understand correctly, an allocation can either receive multiple connections from peers or (xor) initiate *one* connection to a peer. Is my understanding right? - Section 4.4, 2nd paragraph: "If a success response is received, the client will start receiving a ConnectionAttempt indication each time a peer attemps a new connection to the allocated address." This sentence seems to mean that multiple ConnectionAttempt indications can be received, each one with a different XOR-PEER-ADDRESS and CONNECTION-ID. Does it mean that the client can create a new TCP connection to the server and send a ConnectionBind for each for them, effectively creating one data connection for each peer connection? I ask this because it seems that only one data connection (see above) seems possible when initiated from the client. If it is the case, why the asymmetry? - Section 4.6, 1st paragraph: "The client MUST refresh the allocation corresponding to a data connection, using the Refresh request as defined in [I-D.ietf-behave-turn], for as long as it wants to keep the data connection alive." The Refresh must be sent additionally on the data connection or only the control connection? If the Refresh is sent on the data connection, so I suppose that the ConnectionBind request and response should use the Lifetime attribute. If the Refresh is sent only sent on the control connection, then I think that this sentence is redundant with section 4.2. - Section 4.6, 2nd paragraph: Here also why no subsequent connections can be established by the client, but subsequent connections can be received? - Section 5.1, 7th paragraph: "Until a Listen request for this allocation is successfully processed, the server MUST deny any connection attempts received on the relayed transport address." Duplicated with section 5.4, 2nd paragraph. - Section 5.2 and 5.3: A Connect or Listen received on a data connection (i.e. after a ConnectionBind) should be rejected. - Section 5.2, 5th paragraph: "If the connection attempt fails or times out, the server MUST return a XXX (Connection Timeout or Failure) error." The default TCP timeout is 180 seconds, but the STUN transaction timeout is 39.5 seconds (See RFC 5489 Section 7.2.2 paragraph 5). What happen to the stuck connection when the STUN transaction times out? - Section 5.5: What happen if a ConnectionBind is received for a peer data connection closed after the 30 seconds timeout? - Section 5.6, 1st paragraph: "If the allocation associated with a data connection expires, the data connection MUST be closed." If I understood correctly that there can be multiple connections from a Listen, then "...the data connectionS MUST be closed." - Section 5.6: What happen if the peer connection is closed? Nits: Section 4.3, 2nd paragraph: "...request is recevied, if it is a success, the TCP connection on which..." recevied -> received -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From rpenno@juniper.net Sat Mar 7 21:28: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 233683A6A95 for ; Sat, 7 Mar 2009 21:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.544 X-Spam-Level: X-Spam-Status: No, score=-5.544 tagged_above=-999 required=5 tests=[AWL=1.055, 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 zGTlucZnEXTD for ; Sat, 7 Mar 2009 21:28:39 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 7D4BC3A695F for ; Sat, 7 Mar 2009 21:28:32 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSbNXodxVZTAOLRnKuD0D7ag3biV2SjHx@postini.com; Sat, 07 Mar 2009 21:29:12 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sat, 7 Mar 2009 21:28:23 -0800 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Mar 2009 21:28:23 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Mar 2009 21:28:23 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 00:28:22 -0500 Received: from 172.23.1.93 ([172.23.1.93]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Sun, 8 Mar 2009 05:28:20 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sat, 7 Mar 2009 21:28:19 -0800 From: Reinaldo Penno To: marcelo bagnulo braun , Behave WG Message-ID: Thread-Topic: [BEHAVE] [Fwd: Re: nat64-02 review] Thread-Index: AcmfrrBvtIm9mWM2ikaIJONBs/75WQ== In-Reply-To: <49B2CDF8.1060701@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2009 05:28:22.0027 (UTC) FILETIME=[B23D7DB0:01C99FAE] Subject: Re: [BEHAVE] [Fwd: Re: nat64-02 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: Sun, 08 Mar 2009 05:28:40 -0000 Hello, Thanks for addressing my comments. Further responses inline.. On 3/7/09 11:41 AM, "marcelo bagnulo braun" wrote: > >> 5) >> " 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." >> >> Can you cite the reference for using for the time of at least 10 seconds as >> a "MUST"? >> >> > why do we need a reference? We are defining the behaviour in this > document, right? Right. > But, do you think 10 secs is not approapriate? would you use a different > value? which one and why? 'Which one and why' is exactly what is missing from your statement in the draft about the 10 seconds value. So, is this 10 second value based on some empirical evidence, best practices or what? >> 7) >> >> " 3. 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." >> >> This seems to be at odds with REQ-5, REQ-5c of RFC4787 >> >> You use the word "maximum", but those requirements use " c) A default >> value of five minutes or more for the NAT UDP mapping >> timer is RECOMMENDED." >> >> In other words 5 minutes or more is rather different than a maximum of 5 >> minutes. >> >> Maybe you can reference REQ-5c here. >> >> >> > right > this is one open question whether we will be able to afford endpoint > independent mappings for all ports in the scenario of ipv4 depletion > > we will need to solve this question, so for now we leave the possibility > open in the draft > > what is your opinion on this? > If we do not know yet why make a pre-emptive recommendation that is at odds with RFC4787. I would say until we have good evidence we should default to the current recommendation in RFC4787. > Thanks, marcelo > > >> Thanks, >> >> Reinaldo >> >> >> >> >> >> >> >> >> > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From marcelo@it.uc3m.es Sun Mar 8 00:59: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 75DDE28C0DB for ; Sun, 8 Mar 2009 00:59:29 -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 KvMGcjrHUK32 for ; Sun, 8 Mar 2009 00:59:28 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 3FE573A68E5 for ; Sun, 8 Mar 2009 00:59:27 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (81.pool85-53-139.dynamic.orange.es [85.53.139.81]) by smtp01.uc3m.es (Postfix) with ESMTP id 4F48FB56194; Sun, 8 Mar 2009 09:59:57 +0100 (CET) Message-ID: <49B3890D.6030102@it.uc3m.es> Date: Sun, 08 Mar 2009 09:59:57 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) 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-5.6.0.1016-16506.006 Cc: Behave WG Subject: Re: [BEHAVE] [Fwd: Re: nat64-02 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: Sun, 08 Mar 2009 08:59:29 -0000 Reinaldo Penno escribió: > Hello, > > Thanks for addressing my comments. Further responses inline.. > > > On 3/7/09 11:41 AM, "marcelo bagnulo braun" wrote: > > >>> 5) >>> " 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." >>> >>> Can you cite the reference for using for the time of at least 10 seconds as >>> a "MUST"? >>> >>> >>> >> why do we need a reference? We are defining the behaviour in this >> document, right? >> > > Right. > > >> But, do you think 10 secs is not approapriate? would you use a different >> value? which one and why? >> > > 'Which one and why' is exactly what is missing from your statement in the > draft about the 10 seconds value. > i guess which one is not missing, it is 10 secs :-) why, as far as i recall this was input provided by a reviewer I mean, originally the draft didn't handle out of order fragments i.e. dropped the fragments out of order, but it was suggested that the nat64 should support out of order fragments as long as they arrive in a given interval... maybe Iljitsch of Phil have better recollection of why this specific value is in there... > So, is this 10 second value based on some empirical evidence, best practices > or what? > > >>> 7) >>> >>> " 3. 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." >>> >>> This seems to be at odds with REQ-5, REQ-5c of RFC4787 >>> >>> You use the word "maximum", but those requirements use " c) A default >>> value of five minutes or more for the NAT UDP mapping >>> timer is RECOMMENDED." >>> >>> In other words 5 minutes or more is rather different than a maximum of 5 >>> minutes. >>> >>> Maybe you can reference REQ-5c here. >>> >>> >>> >>> >> right >> this is one open question whether we will be able to afford endpoint >> independent mappings for all ports in the scenario of ipv4 depletion >> >> we will need to solve this question, so for now we leave the possibility >> open in the draft >> >> what is your opinion on this? >> >> > > If we do not know yet why make a pre-emptive recommendation that is at odds > with RFC4787. I would say until we have good evidence we should default to > the current recommendation in RFC4787. > > right, that was my take too Now, with all the ipv4 depletion being so present, it seems that it may be worth reconsidering this, or at least open the discussion I mean, even something as conservative as don't do endpoint independence with port 80 seem to provide benefits with not much loss functionality. regards, marcelo >> Thanks, marcelo >> >> >> >>> Thanks, >>> >>> Reinaldo >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > > From marcelo@it.uc3m.es Sun Mar 8 01:31: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 F0FE83A68E0 for ; Sun, 8 Mar 2009 01:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 Zr6S+NpH64eu for ; Sun, 8 Mar 2009 01:31:46 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 241F83A6895 for ; Sun, 8 Mar 2009 01:31:45 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (81.pool85-53-139.dynamic.orange.es [85.53.139.81]) by smtp02.uc3m.es (Postfix) with ESMTP id 0E31265A4B9; Sun, 8 Mar 2009 10:32:16 +0100 (CET) Message-ID: <49B3909F.2050309@it.uc3m.es> Date: Sun, 08 Mar 2009 10:32:15 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dan Wing , 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-5.6.0.1016-16506.006 Subject: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Sun, 08 Mar 2009 09:31:47 -0000 Hi, been through this document and i have a comment: section 2.2. BitTorrent reads BitTorrent trackers use HTTP URIs and DNS names. Thus, if an IPv6- only host running a web browser can connect to an IPv4-only web site using a translator (e.g., using NAT64 and DNS64), that same IPv6-only host running a BitTorrent client can connect to an IPv4-only BitTorrent tracker. While some BitTorrent trackers are beginning to track IPv6 addresses of BitTorrent peers, most trackers only track IPv4 peers. Most content is only available on IPv4. When an IPv6-only BitTorrent peer obtains IPv4 addresses from its tracker, it cannot use those IPv4 addresses. To do so, the BitTorrent client software would need to prefix the IPv4 address with the prefix of a NAT64 that will perform the necessary address family translation on behalf of the IPv6-only BitTorrent client. This could be done with updates to BitTorrent clients to prefix the IPv4 address with the IPv6 prefix of a NAT64 translator which will both authorize and route the communication to the IPv4 BitTorrent peer. BitTorrent clients do not perform this function today. I agree with that, but suppose you upgrade the bittorrent to do this (which probably will happen if more content is available in IPv6) Which would be easier to handle, the well known prefix or the lir prefix? With the well known prefix, the the bittorrent client could simply hardcode the well know prefix and if it detects it is on an ipv6 only host, it can prepend the well know prefix and it may work. With the LIR prefix, the bittorrent client would need to learn the nat64 prefix in order to make any attempt at all. makes sense? regards, marcelo From simon.perreault@viagenie.ca Sun Mar 8 07:13: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 430323A6C08 for ; Sun, 8 Mar 2009 07:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.181, 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 qtsh0ur6rqFb for ; Sun, 8 Mar 2009 07:13:02 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 13C5B3A6A73 for ; Sun, 8 Mar 2009 07:13:02 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 9D21D29E1568; Sun, 8 Mar 2009 10:13:34 -0400 (EDT) Received: from balaise.nomis80.org (unknown [IPv6:2001:5c0:1100:cf00:218:f3ff:fe3d:1af4]) by jazz.viagenie.ca (Postfix) with ESMTP id 1856329E1562; Sun, 8 Mar 2009 10:13:34 -0400 (EDT) Message-ID: <49B3D28D.4020700@viagenie.ca> Date: Sun, 08 Mar 2009 10:13:33 -0400 From: Simon Perreault User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Marc Petit-Huguenin References: <20090304194502.13A203A6830@core3.amsl.com> <49B33F69.7070907@acm.org> In-Reply-To: <49B33F69.7070907@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Sun, 08 Mar 2009 14:13:04 -0000 Marc Petit-Huguenin wrote: > If I understand correctly, an allocation can either receive multiple > connections from peers or (xor) initiate *one* connection to a peer. > Is my understanding right? Right. > - Section 4.4, 2nd paragraph: "If a success response is received, > the client will start receiving a ConnectionAttempt indication each > time a peer attemps a new connection to the allocated address." > > This sentence seems to mean that multiple ConnectionAttempt > indications can be received, each one with a different > XOR-PEER-ADDRESS and CONNECTION-ID. Does it mean that the client > can create a new TCP connection to the server and send a > ConnectionBind for each for them, effectively creating one data > connection for each peer connection? I ask this because it seems > that only one data connection (see above) seems possible when > initiated from the client. If it is the case, why the asymmetry? Above restricts the number of client data connections for a Connect request to one. For Listen requests, one client data connection per peer is still possible. > - Section 4.6, 1st paragraph: "The client MUST refresh the > allocation corresponding to a data connection, using the Refresh > request as defined in [I-D.ietf-behave-turn], for as long as it > wants to keep the data connection alive." > > The Refresh must be sent additionally on the data connection or only > the control connection? If the Refresh is sent on the data > connection, so I suppose that the ConnectionBind request and > response should use the Lifetime attribute. If the Refresh is sent > only sent on the control connection, then I think that this sentence > is redundant with section 4.2. Only on the control connection. No STUN messages are sent after the initial ConnectionBind request/response exchange on the data connection. The additional, non-redundant information is that you cannot keep a data connection open if you let the allocation expire. > - Section 4.6, 2nd paragraph: > > Here also why no subsequent connections can be established by the > client, but subsequent connections can be received? This is restricted by the BSD sockets API. Once it has connect()'ed, a socket cannot be deconnected and reconnected elsewhere. It also cannot start listen()'ing. It's good for nothing and must be closed. The situation is a bit different for sockets once they have listen()'ed. They can receive any number of connections. But they cannot be used for connect()'ing anymore. > - Section 5.1, 7th paragraph: "Until a Listen request for this > allocation is successfully processed, the server MUST deny any > connection attempts received on the relayed transport address." > > Duplicated with section 5.4, 2nd paragraph. I'll remove the 7th paragraph in section 5.1. > - Section 5.2 and 5.3: > > A Connect or Listen received on a data connection (i.e. after a > ConnectionBind) should be rejected. This would be contrary to section 5.5, 6th paragraph: Data received on a client or peer data connection MUST NOT be interpreted as a STUN message. Instead of being rejected, they should be forwarded to the peer as-is. > - Section 5.2, 5th paragraph: "If the connection attempt fails or > times out, the server MUST return a XXX (Connection Timeout or > Failure) error." > > The default TCP timeout is 180 seconds, but the STUN transaction > timeout is 39.5 seconds (See RFC 5489 Section 7.2.2 paragraph 5). > What happen to the stuck connection when the STUN transaction times out? The 39.5 seconds timeout only applies to the initial TCP connection establishment. It does not apply when waiting for STUN responses. However, for a request/response transaction, if the client has not received a response by Ti seconds after it sent the SYN to establish the connection, it considers the transaction to have timed out. Ti SHOULD be configurable and SHOULD have a default of 39.5s. > - Section 5.5: > > What happen if a ConnectionBind is received for a peer data > connection closed after the 30 seconds timeout? An error must be returned. This will be added to the next revision. > - Section 5.6, 1st paragraph: "If the allocation associated with a > data connection expires, the data connection MUST be closed." > > If I understood correctly that there can be multiple connections > from a Listen, then "...the data connectionS MUST be closed." Right. > - Section 5.6: > > What happen if the peer connection is closed? Well, I intended the second paragraph to apply to the client and peer cases by clever usage of the "resp." construct. I shouldn't try to be clever. I'll split the paragraph in two in the next revision. Many thanks for this review! Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From petithug@acm.org Sun Mar 8 09:26: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 E89183A6868 for ; Sun, 8 Mar 2009 09:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.211 X-Spam-Level: X-Spam-Status: No, score=-102.211 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTsSvtUUOAty for ; Sun, 8 Mar 2009 09:26:35 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 31FE23A6809 for ; Sun, 8 Mar 2009 09:26:35 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 180D3DBD40CA; Sun, 8 Mar 2009 16:27:08 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTP id 9BDA56C9843C; Sun, 8 Mar 2009 16:27:07 +0000 (UTC) Message-ID: <49B3F1D6.10400@acm.org> Date: Sun, 08 Mar 2009 09:27:02 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Simon Perreault References: <20090304194502.13A203A6830@core3.amsl.com> <49B33F69.7070907@acm.org> <49B3D28D.4020700@viagenie.ca> In-Reply-To: <49B3D28D.4020700@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Sun, 08 Mar 2009 16:26:36 -0000 Simon Perreault wrote: > Marc Petit-Huguenin wrote: [...] > >> - Section 4.6, 1st paragraph: "The client MUST refresh the >> allocation corresponding to a data connection, using the Refresh >> request as defined in [I-D.ietf-behave-turn], for as long as it >> wants to keep the data connection alive." >> >> The Refresh must be sent additionally on the data connection or only >> the control connection? If the Refresh is sent on the data >> connection, so I suppose that the ConnectionBind request and >> response should use the Lifetime attribute. If the Refresh is sent >> only sent on the control connection, then I think that this sentence >> is redundant with section 4.2. > > Only on the control connection. No STUN messages are sent after the > initial ConnectionBind request/response exchange on the data connection. > > The additional, non-redundant information is that you cannot keep a data > connection open if you let the allocation expire. Hmm, I do not read this in 4.6 but anyway, the client does not know that an allocation expired - or at least not until the next Refresh fails, so it cannot close the data connection immediately. On the other hand if the allocation expires the data connections are closed by the server (5.6 paragraph 1) so that would be unnecessary. Also that there should be some text explaining what happen if the client closes the control connection (i.e. same than allocation expires) > >> - Section 4.6, 2nd paragraph: >> >> Here also why no subsequent connections can be established by the >> client, but subsequent connections can be received? > > This is restricted by the BSD sockets API. Once it has connect()'ed, a > socket cannot be deconnected and reconnected elsewhere. It also cannot > start listen()'ing. It's good for nothing and must be closed. > > The situation is a bit different for sockets once they have listen()'ed. > They can receive any number of connections. But they cannot be used for > connect()'ing anymore. > It it possible to create multiple sockets with SO_REUSEADDR that are all bound to the same IP address and port. The TURN TCP protocol can hide this and simply allow multiple incoming or outgoing connections, simultaneously or sequentially. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From marcelo@it.uc3m.es Sun Mar 8 12:21: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 2CF813A6A5D for ; Sun, 8 Mar 2009 12:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 iH1+z8ueKm62 for ; Sun, 8 Mar 2009 12:21:47 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id F07C43A6B03 for ; Sun, 8 Mar 2009 12:21:46 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (207.pool85-53-150.dynamic.orange.es [85.53.150.207]) by smtp01.uc3m.es (Postfix) with ESMTP id 3AB78B4D7D7 for ; Sun, 8 Mar 2009 20:22:17 +0100 (CET) Message-ID: <49B41AE8.4090403@it.uc3m.es> Date: Sun, 08 Mar 2009 20:22:16 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Behave WG Content-Type: multipart/mixed; boundary="------------080804000206000007070305" Subject: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-01.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, 08 Mar 2009 19:21:48 -0000 This is a multi-part message in MIME format. --------------080804000206000007070305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please find attached a new version of the draft analysing the different possibilities we can use for mapping IPv4 addresses into IPv6 address space, in the context of the v4v6 translation. comments are welcome regards, marcelo -------- Mensaje original -------- Asunto: I-D Action:draft-miyata-behave-prefix64-01.txt Fecha: Sun, 8 Mar 2009 12:15:01 -0700 (PDT) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PREFIX64 Comparison Author(s) : H. Miyata, M. Bagnulo Filename : draft-miyata-behave-prefix64-01.txt Pages : 22 Date : 2009-03-08 This draft compares different IPv6 prefix formats that can be used by IPv6-IPv4 translator to represent IPv4 addresses in the IPv6 Internet. The goal of the draft is asses the benefits and problems of each proposed format and make a recommendation about which prefix to use in the different scenarios considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-miyata-behave-prefix64-01.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. --------------080804000206000007070305 Content-Type: Message/External-body; name="draft-miyata-behave-prefix64-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-miyata-behave-prefix64-01.txt" Content-Type: text/plain Content-ID: <2009-03-08120627.I-D@ietf.org> --------------080804000206000007070305 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 --------------080804000206000007070305-- From simon.perreault@viagenie.ca Sun Mar 8 13:33: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 9D0993A6860 for ; Sun, 8 Mar 2009 13:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.172, 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 nc+WwwhGFp7u for ; Sun, 8 Mar 2009 13:32:59 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 8D6B63A67A3 for ; Sun, 8 Mar 2009 13:32:59 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 7F36329E156A; Sun, 8 Mar 2009 16:33:32 -0400 (EDT) Received: from balaise.nomis80.org (unknown [IPv6:2001:5c0:1100:cf00:218:f3ff:fe3d:1af4]) by jazz.viagenie.ca (Postfix) with ESMTP id E24C729E1562; Sun, 8 Mar 2009 16:33:31 -0400 (EDT) Message-ID: <49B42B9A.30703@viagenie.ca> Date: Sun, 08 Mar 2009 16:33:30 -0400 From: Simon Perreault User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Marc Petit-Huguenin References: <20090304194502.13A203A6830@core3.amsl.com> <49B33F69.7070907@acm.org> <49B3D28D.4020700@viagenie.ca> <49B3F1D6.10400@acm.org> In-Reply-To: <49B3F1D6.10400@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Sun, 08 Mar 2009 20:33:00 -0000 Marc Petit-Huguenin wrote: > It it possible to create multiple sockets with SO_REUSEADDR that are > all bound to the same IP address and port. The TURN TCP protocol > can hide this and simply allow multiple incoming or outgoing > connections, simultaneously or sequentially. Indeed. Hmmm... This means we could do away with the Listen request completely. Unless somebody objects, I'll remove the Listen request in the next revision, as well as all restrictions related to the above. Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From David.Miles@alcatel-lucent.com.au Sun Mar 8 22: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 83E763A6864 for ; Sun, 8 Mar 2009 22:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APHN5DUhEHtn for ; Sun, 8 Mar 2009 22:19:45 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 9A1713A63EC for ; Sun, 8 Mar 2009 22:19:45 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n295KEjI013877 for ; Mon, 9 Mar 2009 00:20:14 -0500 (CDT) Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n295KCwg022032 for ; Mon, 9 Mar 2009 00:20:13 -0500 (CDT) Received: from sgsinsbhs02.ad4.ad.alcatel.com (sgsinsbhs02.ap.lucent.com [135.254.109.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id n294nlFg010349 for ; Mon, 9 Mar 2009 12:49:47 +0800 Received: from SGSINSMBS02.ad4.ad.alcatel.com ([135.254.109.29]) by sgsinsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 13:20:11 +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: Mon, 9 Mar 2009 13:19:53 +0800 Message-ID: <986DCE2E44129444B6435ABE8C9E424D02D5CE0A@SGSINSMBS02.ad4.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Layer2-Aware NAT (draft-miles-behave-l2nat-00) Thread-Index: AcmgdlhcsqF9XOaRSFmUv5LfTG7d5QAAEU/w From: "MILES DAVID" To: X-OriginalArrivalTime: 09 Mar 2009 05:20:11.0183 (UTC) FILETIME=[B81663F0:01C9A076] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130 Subject: [BEHAVE] FW: Layer2-Aware NAT (draft-miles-behave-l2nat-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, 09 Mar 2009 05:19:46 -0000 All, A new method for NAT44 has been posted based on some of the work in the Montreal v4/v6 coexistence meeting and methods described in Dual Stack Lite. L2-Aware NAT proposes a virtual NAT mapping table for each layer2 connection (be that VLAN, ATM, PPP or L2TP [similar to Dual Stack Lite]). We would see this work merging into a larger CGN document. The draft will be presented in the BEHAVE session at IETF74. Comments are most welcome! Best Regards, -David http://tools.ietf.org/html/draft-miles-behave-l2nat-00 Filename: draft-miles-behave-l2nat Revision: 00 Title: Layer2-Aware NAT Creation_date: 2009-03-04 WG ID: Independent Submission Number_of_pages: 16 Abstract: This document describes a "Layer2-Aware" IPv4-to-IPv4 (NAT44) Service Provider NAT function that identifies subscriber traffic based on IP- independent methods such as a link-layer address, VLAN, PPP session, tunnel, etc. in order to allow one to either avoid "double-NAT" (NAT444) of subscriber IP traffic altogether, the need for additional "Shared Service-Provider" IPv4 address space, or partitioning of RFC 1918 space between subscribers. While the mechanisms described in this document may be applicable to a variety of network architectures, the primary focus is on residential "fixed-line" Internet access. From mohamed.boucadair@orange-ftgroup.com Mon Mar 9 00:28: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 33E473A6A53 for ; Mon, 9 Mar 2009 00:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 JLnBzzSW4eY7 for ; Mon, 9 Mar 2009 00:28:03 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id D1DFA3A69CA for ; Mon, 9 Mar 2009 00:28:02 -0700 (PDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 08:28:31 +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: Mon, 9 Mar 2009 08:28:29 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] comment about draft-wing-behave-nat64-referrals-00.txt Thread-Index: Acmf0Ml0l1ktBzIgRWCko4ncbihocgAt2xGw References: <49B3909F.2050309@it.uc3m.es> From: To: , , X-OriginalArrivalTime: 09 Mar 2009 07:28:31.0017 (UTC) FILETIME=[A58BD190:01C9A088] Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Mon, 09 Mar 2009 07:28:04 -0000 Please see inline. Cheers, Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de marcelo bagnulo braun Envoy=E9 : dimanche 8 mars 2009 10:32 =C0 : Dan Wing; Behave WG Objet : [BEHAVE] comment about draft-wing-behave-nat64-referrals-00.txt Hi, been through this document and i have a comment: section 2.2. BitTorrent reads BitTorrent trackers use HTTP URIs and DNS names. Thus, if an IPv6- only host running a web browser can connect to an IPv4-only web site using a translator (e.g., using NAT64 and DNS64), that same IPv6-only host running a BitTorrent client can connect to an IPv4-only BitTorrent tracker. While some BitTorrent trackers are beginning to track IPv6 addresses of BitTorrent peers, most trackers only track IPv4 peers. Most content is only available on IPv4. When an IPv6-only BitTorrent peer obtains IPv4 addresses from its tracker, it cannot use those IPv4 addresses. To do so, the BitTorrent client software would need to prefix the IPv4 address with the prefix of a NAT64 that will perform the necessary address family translation on behalf of the IPv6-only BitTorrent client. This could be done with updates to BitTorrent clients to prefix the IPv4 address with the IPv6 prefix of a NAT64 translator which will both authorize and route the communication to the IPv4 BitTorrent peer. BitTorrent clients do not perform this function today. I agree with that, but suppose you upgrade the bittorrent to do this = (which probably will happen if more content is available in IPv6) Which would be easier to handle, the well known prefix or the lir = prefix? Med: for the application, it is easier to have a IANA assigned prefix.. With the well known prefix, the the bittorrent client could simply = hardcode the well know prefix and if it detects it is on an ipv6 only = host, it can prepend the well know prefix and it may work. With the LIR = prefix, the bittorrent client would need to learn the nat64 prefix in = order to make any attempt at all. makes sense? Med: This assumes the availability of inter-domain routes to reach those = WK prefixes... regards, marcelo _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From marcelo@it.uc3m.es Mon Mar 9 00:57: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 EB2503A6820 for ; Mon, 9 Mar 2009 00:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.347 X-Spam-Level: X-Spam-Status: No, score=-6.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 Iosoq1HPfQhk for ; Mon, 9 Mar 2009 00:57:35 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id C04173A6B8C for ; Mon, 9 Mar 2009 00:57:34 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (207.pool85-53-150.dynamic.orange.es [85.53.150.207]) by smtp02.uc3m.es (Postfix) with ESMTP id 8D021683000; Mon, 9 Mar 2009 08:58:05 +0100 (CET) Message-ID: <49B4CC0F.5040304@it.uc3m.es> Date: Mon, 09 Mar 2009 08:58:07 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> In-Reply-To: <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16508.005 Cc: behave@ietf.org, dwing@cisco.com Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Mon, 09 Mar 2009 07:57:36 -0000 mohamed.boucadair@orange-ftgroup.com escribió: > Please see inline. > Cheers, > Med > > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de marcelo bagnulo braun > Envoyé : dimanche 8 mars 2009 10:32 > Ŕ : Dan Wing; Behave WG > Objet : [BEHAVE] comment about draft-wing-behave-nat64-referrals-00.txt > > Hi, > > been through this document and i have a comment: > > > section 2.2. BitTorrent reads > > BitTorrent trackers use HTTP URIs and DNS names. Thus, if an IPv6- > only host running a web browser can connect to an IPv4-only web site > using a translator (e.g., using NAT64 and DNS64), that same IPv6-only > host running a BitTorrent client can connect to an IPv4-only > BitTorrent tracker. While some BitTorrent trackers are beginning to > track IPv6 addresses of BitTorrent peers, most trackers only track > IPv4 peers. Most content is only available on IPv4. > > When an IPv6-only BitTorrent peer obtains IPv4 addresses from its > tracker, it cannot use those IPv4 addresses. To do so, the > BitTorrent client software would need to prefix the IPv4 address with > the prefix of a NAT64 that will perform the necessary address family > translation on behalf of the IPv6-only BitTorrent client. This could > be done with updates to BitTorrent clients to prefix the IPv4 address > with the IPv6 prefix of a NAT64 translator which will both authorize > and route the communication to the IPv4 BitTorrent peer. BitTorrent > clients do not perform this function today. > > I agree with that, but suppose you upgrade the bittorrent to do this (which probably will happen if more content is available in IPv6) > > Which would be easier to handle, the well known prefix or the lir prefix? > > > Med: for the application, it is easier to have a IANA assigned prefix.. > > > With the well known prefix, the the bittorrent client could simply hardcode the well know prefix and if it detects it is on an ipv6 only host, it can prepend the well know prefix and it may work. With the LIR prefix, the bittorrent client would need to learn the nat64 prefix in order to make any attempt at all. > > makes sense? > > > Med: This assumes the availability of inter-domain routes to reach those WK prefixes... > > I don't think so Please check draft-miyata-behave-prefix64-01.txt just posted, the section about referrals The Well known prefix, is passed from one domain to another doamin in the referral. Once it is received in the other domain, it is used. So, what is needed is that both the originator of the referral and that the receiver of the referral have translation services. But if they don't have translation services, the referral won't work in any case cause the IPv4 only host is no reachable (this is a bit tricky to describe in a few setneces, so i reccomend you to check the referral section in the draft) Regards, marcelo > regards, marcelo > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From mohamed.boucadair@orange-ftgroup.com Mon Mar 9 01:19: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 15E233A6AE5 for ; Mon, 9 Mar 2009 01:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ju2Z35zBnI5S for ; Mon, 9 Mar 2009 01:19:48 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id BACE63A69DD for ; Mon, 9 Mar 2009 01:19:47 -0700 (PDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 09:20:17 +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: Mon, 9 Mar 2009 09:20:15 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007D4EF0C@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] comment about draft-wing-behave-nat64-referrals-00.txt Thread-Index: AcmgjMi5DO3BGt4DTC2drTHqNUFXNwAAdIKg References: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> <49B4CC0F.5040304@it.uc3m.es> From: To: X-OriginalArrivalTime: 09 Mar 2009 08:20:17.0517 (UTC) FILETIME=[E12A19D0:01C9A08F] Cc: behave@ietf.org, dwing@cisco.com Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Mon, 09 Mar 2009 08:19:49 -0000 Thank Marcelo for the pointer. Please see inline. Cheers, Med=20 -----Message d'origine----- De : marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 Envoy=E9 : lundi 9 mars 2009 08:58 =C0 : BOUCADAIR Mohamed RD-CORE-CAE Cc : dwing@cisco.com; behave@ietf.org Objet : Re: [BEHAVE] comment about = draft-wing-behave-nat64-referrals-00.txt mohamed.boucadair@orange-ftgroup.com escribi=F3: > Please see inline. > Cheers, > Med > > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la=20 > part de marcelo bagnulo braun Envoy=E9 : dimanche 8 mars 2009 10:32 = =C0 :=20 > Dan Wing; Behave WG Objet : [BEHAVE] comment about=20 > draft-wing-behave-nat64-referrals-00.txt > > Hi, > > been through this document and i have a comment: > > > section 2.2. BitTorrent reads > > BitTorrent trackers use HTTP URIs and DNS names. Thus, if an IPv6- > only host running a web browser can connect to an IPv4-only web = site > using a translator (e.g., using NAT64 and DNS64), that same = IPv6-only > host running a BitTorrent client can connect to an IPv4-only > BitTorrent tracker. While some BitTorrent trackers are beginning = to > track IPv6 addresses of BitTorrent peers, most trackers only track > IPv4 peers. Most content is only available on IPv4. > > When an IPv6-only BitTorrent peer obtains IPv4 addresses from its > tracker, it cannot use those IPv4 addresses. To do so, the > BitTorrent client software would need to prefix the IPv4 address = with > the prefix of a NAT64 that will perform the necessary address = family > translation on behalf of the IPv6-only BitTorrent client. This = could > be done with updates to BitTorrent clients to prefix the IPv4 = address > with the IPv6 prefix of a NAT64 translator which will both = authorize > and route the communication to the IPv4 BitTorrent peer. = BitTorrent > clients do not perform this function today. > > I agree with that, but suppose you upgrade the bittorrent to do this=20 > (which probably will happen if more content is available in IPv6) > > Which would be easier to handle, the well known prefix or the lir = prefix? > > > Med: for the application, it is easier to have a IANA assigned = prefix.. > > > With the well known prefix, the the bittorrent client could simply = hardcode the well know prefix and if it detects it is on an ipv6 only = host, it can prepend the well know prefix and it may work. With the LIR = prefix, the bittorrent client would need to learn the nat64 prefix in = order to make any attempt at all. > > makes sense? > > > Med: This assumes the availability of inter-domain routes to reach = those WK prefixes... > > =20 I don't think so Please check draft-miyata-behave-prefix64-01.txt just posted, the = section about referrals The Well known prefix, is passed from one domain = to another doamin in the referral. Once it is received in the other domain, it is used. So, what is needed = is that both the originator of the referral and that the receiver of the = referral have translation services. But if they don't have translation = services, the referral won't work in any case cause the IPv4 only host = is no reachable Med: I read that section. My point is that the "translation service" may = not be connected to the same BGP domain as for the originator or the = receiver. In this case, a routing issue may be raised when using a WK = prefix, since no IP routes may be available. BT application *** can not = *** ensure that a successful communication will be experienced even if = the referral procedure is implemented. =20 (this is a bit tricky to describe in a few setneces, so i reccomend you = to check the referral section in the draft) Regards, marcelo > regards, marcelo > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > =20 From marcelo@it.uc3m.es Mon Mar 9 01:50: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 BF7F03A6BE0 for ; Mon, 9 Mar 2009 01:50:41 -0700 (PDT) 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 qDtCuTO7v5Wg for ; Mon, 9 Mar 2009 01:50:40 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 6D7A13A6B44 for ; Mon, 9 Mar 2009 01:50:40 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (207.pool85-53-150.dynamic.orange.es [85.53.150.207]) by smtp01.uc3m.es (Postfix) with ESMTP id 3B1DD499643; Mon, 9 Mar 2009 09:51:11 +0100 (CET) Message-ID: <49B4D87F.3010302@it.uc3m.es> Date: Mon, 09 Mar 2009 09:51:11 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> <49B4CC0F.5040304@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EF0C@ftrdmel3> In-Reply-To: <6CF039C5B32037498B02251E11CDE6B007D4EF0C@ftrdmel3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16508.006 Cc: behave@ietf.org, dwing@cisco.com Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Mon, 09 Mar 2009 08:50:41 -0000 mohamed.boucadair@orange-ftgroup.com escribió: > Thank Marcelo for the pointer. > > Please see inline. > > Cheers, > Med > > -----Message d'origine----- > De : marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Envoyé : lundi 9 mars 2009 08:58 > Ŕ : BOUCADAIR Mohamed RD-CORE-CAE > Cc : dwing@cisco.com; behave@ietf.org > Objet : Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-00.txt > > mohamed.boucadair@orange-ftgroup.com escribió: > >> Please see inline. >> Cheers, >> Med >> >> >> -----Message d'origine----- >> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la >> part de marcelo bagnulo braun Envoyé : dimanche 8 mars 2009 10:32 Ŕ : >> Dan Wing; Behave WG Objet : [BEHAVE] comment about >> draft-wing-behave-nat64-referrals-00.txt >> >> Hi, >> >> been through this document and i have a comment: >> >> >> section 2.2. BitTorrent reads >> >> BitTorrent trackers use HTTP URIs and DNS names. Thus, if an IPv6- >> only host running a web browser can connect to an IPv4-only web site >> using a translator (e.g., using NAT64 and DNS64), that same IPv6-only >> host running a BitTorrent client can connect to an IPv4-only >> BitTorrent tracker. While some BitTorrent trackers are beginning to >> track IPv6 addresses of BitTorrent peers, most trackers only track >> IPv4 peers. Most content is only available on IPv4. >> >> When an IPv6-only BitTorrent peer obtains IPv4 addresses from its >> tracker, it cannot use those IPv4 addresses. To do so, the >> BitTorrent client software would need to prefix the IPv4 address with >> the prefix of a NAT64 that will perform the necessary address family >> translation on behalf of the IPv6-only BitTorrent client. This could >> be done with updates to BitTorrent clients to prefix the IPv4 address >> with the IPv6 prefix of a NAT64 translator which will both authorize >> and route the communication to the IPv4 BitTorrent peer. BitTorrent >> clients do not perform this function today. >> >> I agree with that, but suppose you upgrade the bittorrent to do this >> (which probably will happen if more content is available in IPv6) >> >> Which would be easier to handle, the well known prefix or the lir prefix? >> >> >> Med: for the application, it is easier to have a IANA assigned prefix.. >> >> >> With the well known prefix, the the bittorrent client could simply hardcode the well know prefix and if it detects it is on an ipv6 only host, it can prepend the well know prefix and it may work. With the LIR prefix, the bittorrent client would need to learn the nat64 prefix in order to make any attempt at all. >> >> makes sense? >> >> >> Med: This assumes the availability of inter-domain routes to reach those WK prefixes... >> >> >> > I don't think so > Please check draft-miyata-behave-prefix64-01.txt just posted, the section about referrals The Well known prefix, is passed from one domain to another doamin in the referral. > Once it is received in the other domain, it is used. So, what is needed is that both the originator of the referral and that the receiver of the referral have translation services. But if they don't have translation services, the referral won't work in any case cause the IPv4 only host is no reachable > > > Med: I read that section. My point is that the "translation service" may not be connected to the same BGP domain as for the originator or the receiver. In this case, a routing issue may be raised when using a WK prefix, since no IP routes may be available. BT application *** can not *** ensure that a successful communication will be experienced even if the referral procedure is implemented. > > sure, i fully agree with that But this has nothing to do with the referral operation I mean, if the receiver of the referral is IPv6 only and has no access to the services of a translator, it means that it cannot communicate to IPv4 only hosts, right? (with or wihtout referrals) So the problem for this host is much more general than the referal breaking, but all communications with IPv4 internet is breaking I mean, it would be the same if a hots is unreachable cause it has no connectivity, a referal to that host won't work, right, but no communication would work, so not a specific problem of the referral. In other words, if you want to evaluate if referrals work, you need to assume that that it is possible for the 3 host to exchange packet among them, If that condition does not hold, then, there is no connectivyt and even regular client server communication would break. Makes sense? regards, marcelo > (this is a bit tricky to describe in a few setneces, so i reccomend you to check the referral section in the draft) > > Regards, marcelo > > > >> regards, marcelo >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> >> > > > From vincent@clarinet.u-strasbg.fr Mon Mar 9 01:51: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 E67EB3A6B44 for ; Mon, 9 Mar 2009 01:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 sLOFrH+EIHXL for ; Mon, 9 Mar 2009 01:51:05 -0700 (PDT) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.158]) by core3.amsl.com (Postfix) with ESMTP id A98753A6901 for ; Mon, 9 Mar 2009 01:51:04 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n298oKHN074788 ; Mon, 9 Mar 2009 09:50:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 5D1C99CF660; Mon, 9 Mar 2009 09:50:20 +0100 (CET) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZSotCBBkRxq; Mon, 9 Mar 2009 09:50:19 +0100 (CET) Received: from [130.79.91.216] (kitchenet.u-strasbg.fr [130.79.91.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: vincent) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 373E89CF651; Mon, 9 Mar 2009 09:50:19 +0100 (CET) Message-ID: <49B4D84A.2000000@clarinet.u-strasbg.fr> Date: Mon, 09 Mar 2009 09:50:18 +0100 From: Sebastien Vincent User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Philip Matthews References: <3975D16E-3CFB-40E0-B208-247A055A9BDB@magma.ca> In-Reply-To: <3975D16E-3CFB-40E0-B208-247A055A9BDB@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [130.79.200.158]); Mon, 09 Mar 2009 09:50:20 +0100 (CET) X-Virus-Scanned: ClamAV 0.94.2/9080/Fri Mar 6 20:13:38 2009 on mr8.u-strasbg.fr X-Virus-Status: Clean Cc: Behave WG Subject: Re: [BEHAVE] TURN-13 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, 09 Mar 2009 08:51:06 -0000 Hello folks, A new version of TurnServer is available (turnserver-0.2.2) on sourceforge (https://sourceforge.net/project/showfiles.php?group_id=234986). In two word it add support for turn-13 specification and experimental multiple uplink interfaces support (warning: configuration file syntax have changed for listen_address and listen_addressv6). Regards, -- Sebastien Vincent http://www.turnserver.org https://sourceforge.net/projects/turnserver/ Philip Matthews a écrit : > I have just posted version 13 of the TURN specification > (draft-ietf-behave-turn-13). This version addresses the comments > received during IETF Last Call. > > Substantive changes from -12 to -13: > > * Added a new error code: 403 (Forbidden), and specified that this > error code is returned when the server processes a CreatePermission or > ChannelBind request and decides that it wishes to reject the supplied > IP address and port combination for administrative reasons. Version > -12 did not specify an error code to use in this situation, and none > of the existing error codes seemed appropriate. (Thanks to Magnus and > others for catching this) > > * In the IANA considerations section, added a request to IANA to > establish a registry for channel numbers. This originally seemed > unnecessary to me, given the nature of channel numbers, but enough > people asked about this, so I went ahead and did it. > > * Clarified the usage of the nonce value in the Long-Term Credential > Mechanism: a new random nonce SHOULD be selected for each Allocate > attempt, and the nonce SHOULD be expired at least once every hour. > Also referenced RFC 4086 for guidelines on selecting the nonce value. > > In addition to these technical changes, there are a number of > editorial changes that either fixed typos or that cleaned up the > presentation in various places. > > There were two notable proposed changes that did NOT make it into this > version: > * A request to add support for relaying ICMP messages, and > * A request to change the lifetime of a channel binding from 10 > minutes to 5 minutes. > Neither change gathered enough WG support to be added. > > Many thanks to everyone who submitted comments. > > Submitting this version of TURN was a bit of a challenge, given all > the IPR boilerplate and related tool issues. TURN is produced using > Bill Fenner's xxe plug-in for XMLMind and the on-line conversion tool > at xml.resource.org, neither one of which was updated at the time of > submission. Thanks to Cullen for figuring out how to produce an I-D > that includes the necessary clause about pre-Nov10 text and which > passes the idnits tool, and to Dan for pointing me at Cullen's > instructions. It is ironic that all this blew up for version -13, > especially since this version is likely the one that will go to IESG > evaluation. > > - Philip > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From pierre.levis@orange-ftgroup.com Mon Mar 9 02:02: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 612D03A6901; Mon, 9 Mar 2009 02:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 OiGcpUCBoVpd; Mon, 9 Mar 2009 02:02:39 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id CEFA93A672F; Mon, 9 Mar 2009 02:02:38 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 10:03:10 +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: Mon, 9 Mar 2009 10:03:09 +0100 Message-ID: In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D02D5CE05@SGSINSMBS02.ad4.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [shara] Layer2-Aware NAT (draft-miles-behave-l2nat-00) Thread-Index: AcmgdlhcsqF9XOaRSFmUv5LfTG7d5QAHWkaA References: <986DCE2E44129444B6435ABE8C9E424D02D5CE05@SGSINSMBS02.ad4.ad.alcatel.com> From: To: , , , X-OriginalArrivalTime: 09 Mar 2009 09:03:10.0792 (UTC) FILETIME=[DEF4B480:01C9A095] Subject: Re: [BEHAVE] [shara] Layer2-Aware NAT (draft-miles-behave-l2nat-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, 09 Mar 2009 09:02:40 -0000 Hi, Very interesting to cope with the IPv4 public AND private address = exhaustion. Actually what you propose can be used not only for CGN but also for port = range solutions. In port range solutions we have a PRR (Port Range Router) in the ISP = network instead of a CGN, and we are also confronted with routing = between CPEs and PRR. As you mention, the best way would be IPv6 encap, but in case IPv6 is = not deployed in the CPEs and access, Layer2-aware mechanisms are good = alternatives. I back the proposal of a larger CGN document. Regards Pierre -----Message d'origine----- De : shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] De la part = de MILES DAVID Envoy=E9 : lundi 9 mars 2009 06:18 =C0 : behave@ietf.org; shara@ietf.org; Mark Townsley Objet : [shara] Layer2-Aware NAT (draft-miles-behave-l2nat-00) All, A new method for NAT44 has been posted based on some of the work in the = Montreal v4/v6 coexistence meeting and methods described in Dual Stack = Lite. L2-Aware NAT proposes a virtual NAT mapping table for each layer2 = connection (be that VLAN, ATM, PPP or L2TP [similar to Dual Stack = Lite]). We would see this work merging into a larger CGN document. The draft = will be presented in the BEHAVE session at IETF74. Best Regards, -David http://tools.ietf.org/html/draft-miles-behave-l2nat-00 Filename: draft-miles-behave-l2nat Revision: 00 Title: Layer2-Aware NAT Creation_date: 2009-03-04 WG ID: Independent Submission Number_of_pages: 16 Abstract: This document describes a "Layer2-Aware" IPv4-to-IPv4 (NAT44) Service = Provider NAT function that identifies subscriber traffic based on IP- = independent methods such as a link-layer address, VLAN, PPP session, = tunnel, etc. in order to allow one to either avoid "double-NAT" (NAT444) of subscriber IP traffic altogether, the need for additional = "Shared Service-Provider" IPv4 address space, or partitioning of RFC 1918 space between subscribers. While the mechanisms described in this = document may be applicable to a variety of network architectures, the = primary focus is on residential "fixed-line" Internet access. _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From mohamed.boucadair@orange-ftgroup.com Mon Mar 9 02:08: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 5E2843A6BCC for ; Mon, 9 Mar 2009 02:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 zROYB3hUcedn for ; Mon, 9 Mar 2009 02:08:32 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 04FF93A69CF for ; Mon, 9 Mar 2009 02:08:31 -0700 (PDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 10:09:00 +0100 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: Mon, 9 Mar 2009 10:08:58 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007D4EFBF@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] comment about draft-wing-behave-nat64-referrals-00.txt Thread-Index: AcmglDXmOrTb8oodQhSZyUeJZ9WfmQAAI4GQ References: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> <49B4CC0F.5040304@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EF0C@ftrdmel3> <49B4D87F.3010302@it.uc3m.es> From: To: X-OriginalArrivalTime: 09 Mar 2009 09:09:00.0051 (UTC) FILETIME=[AF216630:01C9A096] Cc: behave@ietf.org, dwing@cisco.com Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Mon, 09 Mar 2009 09:08:33 -0000 > I don't think so > Please check draft-miyata-behave-prefix64-01.txt just posted, the section about referrals The Well known prefix, is passed from one domain to another doamin in the referral. > Once it is received in the other domain, it is used. So, what is=20 > needed is that both the originator of the referral and that the=20 > receiver of the referral have translation services. But if they don't=20 > have translation services, the referral won't work in any case cause=20 > the IPv4 only host is no reachable > > > Med: I read that section. My point is that the "translation service" may not be connected to the same BGP domain as for the originator or the receiver. In this case, a routing issue may be raised when using a WK prefix, since no IP routes may be available. BT application *** can not *** ensure that a successful communication will be experienced even if the referral procedure is implemented. =20 > > =20 sure, i fully agree with that Med: So, you agree that when a WK prefix is used than it may not lead to successful communications if implemented by BitTorrent.. But this has nothing to do with the referral operation I mean, if the receiver of the referral is IPv6 only and has no access to the services of a translator, it means that it cannot communicate to IPv4 only hosts, right? (with or wihtout referrals)=20 Med: Fully agree. And this is mainly the limitation of the referral procedure in case of BT (or even SIP) when a hard coded prefix of the translation service is used.=20 So the problem for this host is much more general than the referal breaking, but all communications with IPv4 internet is breaking Med: the problem of this node is that it is unable to discover a **valid** translation service since it is biased by the "hard coded WK IPv6 prefix". I mean, it would be the same if a hots is unreachable cause it has no connectivity, a referal to that host won't work, right, but no communication would work, so not a specific problem of the referral. In other words, if you want to evaluate if referrals work, you need to assume that that it is possible for the 3 host to exchange packet among them, If that condition does not hold, then, there is no connectivyt and even regular client server communication would break. Med: Fully agreed. But, things are more complicated because of the usage of hard coded IPv6 prefix instead of dynamic discovery of translation service. The point is that a WK prefix may be simple to be implemented by application, but some complications may be raised such as routing issues. Do you agree with this?=20 Cheers Med From marcelo@it.uc3m.es Mon Mar 9 02: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 758E03A6A64 for ; Mon, 9 Mar 2009 02:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.357 X-Spam-Level: X-Spam-Status: No, score=-6.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 DBTEqaVYAH44 for ; Mon, 9 Mar 2009 02:34:00 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 4945D3A68DF for ; Mon, 9 Mar 2009 02:33:59 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (207.pool85-53-150.dynamic.orange.es [85.53.150.207]) by smtp02.uc3m.es (Postfix) with ESMTP id C372B661ACE; Mon, 9 Mar 2009 10:34:31 +0100 (CET) Message-ID: <49B4E2A7.60405@it.uc3m.es> Date: Mon, 09 Mar 2009 10:34:31 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> <49B4CC0F.5040304@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EF0C@ftrdmel3> <49B4D87F.3010302@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EFBF@ftrdmel3> In-Reply-To: <6CF039C5B32037498B02251E11CDE6B007D4EFBF@ftrdmel3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16508.006 Cc: behave@ietf.org, dwing@cisco.com Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Mon, 09 Mar 2009 09:34:01 -0000 mohamed.boucadair@orange-ftgroup.com escribió: >> I don't think so >> Please check draft-miyata-behave-prefix64-01.txt just posted, the >> > section about referrals The Well known prefix, is passed from one domain > to another doamin in the referral. > >> Once it is received in the other domain, it is used. So, what is >> needed is that both the originator of the referral and that the >> receiver of the referral have translation services. But if they don't >> have translation services, the referral won't work in any case cause >> the IPv4 only host is no reachable >> >> >> Med: I read that section. My point is that the "translation service" >> > may not be connected to the same BGP domain as for the originator or the > receiver. In this case, a routing issue may be raised when using a WK > prefix, since no IP routes may be available. BT application *** can not > *** ensure that a successful communication will be experienced even if > the referral procedure is implemented. > >> >> > sure, i fully agree with that > > > Med: So, you agree that when a WK prefix is used than it may not lead to > successful communications if implemented by BitTorrent.. > > > But this has nothing to do with the referral operation I mean, if the > receiver of the referral is IPv6 only and has no access to the services > of a translator, it means that it cannot communicate to > IPv4 only hosts, right? (with or wihtout referrals) > > Med: Fully agree. And this is mainly the limitation of the referral > procedure in case of BT (or even SIP) when a hard coded prefix of the > translation service is used. > it seems we are diverging... I understood that you mentioned before that the receiver of the referral had no access to the translator services, so it has not access to the v4 internet it has nothing to do with the prefix being hardcoded. > So the problem for this host is much more general than the referal > breaking, but all communications with IPv4 internet is breaking > > > Med: the problem of this node is that it is unable to discover a > **valid** translation service since it is biased by the "hard coded WK > IPv6 prefix". > > don't understand could you make a picture or something to put an example of what you mean? > I mean, it would be the same if a hots is unreachable cause it has no > connectivity, a referal to that host won't work, right, but no > communication would work, so not a specific problem of the referral. > > In other words, if you want to evaluate if referrals work, you need to > assume that that it is possible for the 3 host to exchange packet among > them, If that condition does not hold, then, there is no connectivyt and > even regular client server communication would break. > > > Med: Fully agreed. But, things are more complicated because of the usage > of hard coded IPv6 prefix instead of dynamic discovery of translation > service. hardcoding a prefix allows dynamic discovery of the translation service. what you don't need is to discover the rpefix used for that but any box can annoucne the prefix and provide the services. Is like having a well known name for a service. You just send packet to that naem and you know what service you will get > The point is that a WK prefix may be simple to be implemented > by application, but some complications may be raised such as routing > issues. Do you agree with this? > > No please provide a specific example of a complication on routing Regards, marcelo > Cheers > Med > > From marcelo@it.uc3m.es Mon Mar 9 03:02: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 B5CD23A6811 for ; Mon, 9 Mar 2009 03:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.362 X-Spam-Level: X-Spam-Status: No, score=-6.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 65jvyRehlBDL for ; Mon, 9 Mar 2009 03:02:19 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 9D9C63A6A19 for ; Mon, 9 Mar 2009 03:02:18 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (207.pool85-53-150.dynamic.orange.es [85.53.150.207]) by smtp01.uc3m.es (Postfix) with ESMTP id A4A43B8A169 for ; Mon, 9 Mar 2009 11:02:49 +0100 (CET) Message-ID: <49B4E949.3040601@it.uc3m.es> Date: Mon, 09 Mar 2009 11:02:49 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Behave WG Content-Type: multipart/mixed; boundary="------------010601040000060503080900" Subject: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-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, 09 Mar 2009 10:02:19 -0000 This is a multi-part message in MIME format. --------------010601040000060503080900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have submitted a new version of this one, cause i missed one set of comments is received in the previous one sorry for the confusion regards, marcelo -------- Mensaje original -------- Asunto: I-D Action:draft-miyata-behave-prefix64-02.txt Fecha: Mon, 9 Mar 2009 02:45:02 -0700 (PDT) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PREFIX64 Comparison Author(s) : H. Miyata, M. Bagnulo Filename : draft-miyata-behave-prefix64-02.txt Pages : 24 Date : 2009-03-09 This draft compares different IPv6 prefix formats that can be used by IPv6-IPv4 translator to represent IPv4 addresses in the IPv6 Internet. The goal of the draft is asses the benefits and problems of each proposed format and make a recommendation about which prefix to use in the different scenarios considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-miyata-behave-prefix64-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. --------------010601040000060503080900 Content-Type: Message/External-body; name="draft-miyata-behave-prefix64-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-miyata-behave-prefix64-02.txt" Content-Type: text/plain Content-ID: <2009-03-09024242.I-D@ietf.org> --------------010601040000060503080900 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 --------------010601040000060503080900-- From bbl@lowekamp.net Mon Mar 9 04:54: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 B87D13A6991 for ; Mon, 9 Mar 2009 04:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=0.833, 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 x+Ql4IIX0Liu for ; Mon, 9 Mar 2009 04:54:45 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id EFA9C3A685C for ; Mon, 9 Mar 2009 04:54:44 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so1254401qwe.31 for ; Mon, 09 Mar 2009 04:55:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.110.21 with SMTP id l21mr2345982qcp.26.1236599718553; Mon, 09 Mar 2009 04:55:18 -0700 (PDT) Date: Mon, 9 Mar 2009 07:55:18 -0400 Message-ID: From: Bruce Lowekamp To: behave Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] draft-ietf-behave-nat-behavior-discovery-06 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, 09 Mar 2009 11:54:45 -0000 -06 of nat-behavior discovery has been posted. Changes in this revision are fairly minimal to address comments received. from draft-ietf-behave-nat-behavior-discovery-05 * In applicability section, add explicit requirement that citing drafts must specify how they handle failure * Add new subsection on selecting the source port used for tests, covering both requirements that the same port be used for tests as for the application and dependencies on previous bindings. Reference that section explicitly for tests that are sensitive to previous binding state. * Change SRV discovery to stun-behavior for UDP and TCP and stun-behaviors for TLS/TCP. * Add SRV registry subsection to IANA section. From root@core3.amsl.com Mon Mar 9 05: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 8B63B3A6991; Mon, 9 Mar 2009 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309120001.8B63B3A6991@core3.amsl.com> Date: Mon, 9 Mar 2009 05:00:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-nat-behavior-discovery-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: Mon, 09 Mar 2009 12: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 : NAT Behavior Discovery Using STUN Author(s) : D. MacDonald, B. Lowekamp Filename : draft-ietf-behave-nat-behavior-discovery-06.txt Pages : 32 Date : 2009-03-09 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-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-nat-behavior-discovery-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09044849.I-D@ietf.org> --NextPart-- From Remi.Denis-Courmont@nokia.com Mon Mar 9 06: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 AFE493A6C87 for ; Mon, 9 Mar 2009 06:53:53 -0700 (PDT) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 4NvERjp-NLge for ; Mon, 9 Mar 2009 06:53:52 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 88A883A6C57 for ; Mon, 9 Mar 2009 06:53:52 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n29DrLxn010206 for ; Mon, 9 Mar 2009 15:54:22 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 15:53:32 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 15:53:21 +0200 Received: from leon.remlab.net (esdhcp041160.research.nokia.com [172.21.41.160]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n29DrKcU014752 for ; Mon, 9 Mar 2009 15:53:20 +0200 Content-Language: fr-FR From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: behave@ietf.org Date: Mon, 9 Mar 2009 15:53:42 +0200 User-Agent: KMail/1.11.0 (Linux/2.6.28.7; KDE/4.2.0; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903091553.42943.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 09 Mar 2009 13:53:21.0470 (UTC) FILETIME=[688755E0:01C9A0BE] X-Nokia-AV: Clean Subject: [BEHAVE] Fwd: New Version Notification for draft-denis-behave-v4v6exthdr-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: Mon, 09 Mar 2009 13:53:53 -0000 Hello, This update fixes most of the comments received this far, and a bug in the= =20 wire format. As usual, comments welcome. =2D--------- Forwarded Message ---------- Subject: New Version Notification for draft-denis-behave-v4v6exthdr-01 Date: lundi 09 mars 2009 =46rom: "ext IETF I-D Submission Tool" To: "Denis-Courmont Remi (Nokia-D/Helsinki)" A new version of I-D, draft-denis-behave-v4v6exthdr-01.txt has been=20 successfuly submitted by Remi Denis-Courmont and posted to the IETF=20 repository. =46ilename: draft-denis-behave-v4v6exthdr Revision: 01 Title: IPv6 destination header option for IPv4 translator mapping=20 notification Creation_date: 2009-03-09 WG ID: Independent Submission Number_of_pages: 13 Abstract: This memo defines a new IPv6 Destination header option to convey the transport mapping information from an IPv4-IPv4 protocol translator to the IPv6 end of a protocol-translated packet flow. = =20 The IETF Secretariat. =2D------------------------------------------------------ =2D-=20 R=E9mi Denis-Courmont Maemo Software, Nokia Devices R&D From dwing@cisco.com Mon Mar 9 11:56: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 E8E963A6BE9 for ; Mon, 9 Mar 2009 11:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 JtOGAbuv8w+Z for ; Mon, 9 Mar 2009 11:56:30 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2FED93A6C2B for ; Mon, 9 Mar 2009 11:56:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,330,1233532800"; d="scan'208";a="140770857" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2009 18:56:56 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n29IuuHg032113; Mon, 9 Mar 2009 11:56:56 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n29IuuQH025811; Mon, 9 Mar 2009 18:56:56 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" , "'Behave WG'" References: <49B3909F.2050309@it.uc3m.es> Date: Mon, 9 Mar 2009 11:56:56 -0700 Message-ID: <071a01c9a0e8$d1972450$c2f0200a@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: <49B3909F.2050309@it.uc3m.es> Thread-Index: Acmf0Mcme0HdoI7RQCSyI/fRW0CXeABFBwGg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3137; t=1236625016; x=1237489016; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20comment=20about=20draft-wing-behave-nat 64-referrals-00.txt |Sender:=20; bh=B4UNZoPRQf5wLPS5jJ1vVWV/0HlWq38hLnyZybBSO8w=; b=huLC5WYog1IH2T/lvfi8aM9L7BgQVcOMUBGhzyKpmwP/MyQpSUidoQODjC e+dPymB1FL/6vnBaLTNJBPQ+/cOzyNrOKoQ3I6bfG7qR258GQlxnIeuIRQ6f xZ3PKxixSa; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Mon, 09 Mar 2009 18:56:31 -0000 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Sunday, March 08, 2009 1:32 AM > To: Dan Wing; Behave WG > Subject: comment about draft-wing-behave-nat64-referrals-00.txt > > Hi, > > been through this document and i have a comment: > > > section 2.2. BitTorrent reads > > BitTorrent trackers use HTTP URIs and DNS names. Thus, if an IPv6- > only host running a web browser can connect to an > IPv4-only web site > using a translator (e.g., using NAT64 and DNS64), that > same IPv6-only > host running a BitTorrent client can connect to an IPv4-only > BitTorrent tracker. While some BitTorrent trackers are > beginning to > track IPv6 addresses of BitTorrent peers, most trackers only track > IPv4 peers. Most content is only available on IPv4. > > When an IPv6-only BitTorrent peer obtains IPv4 addresses from its > tracker, it cannot use those IPv4 addresses. To do so, the > BitTorrent client software would need to prefix the IPv4 > address with > the prefix of a NAT64 that will perform the necessary > address family > translation on behalf of the IPv6-only BitTorrent client. > This could > be done with updates to BitTorrent clients to prefix the > IPv4 address > with the IPv6 prefix of a NAT64 translator which will both > authorize > and route the communication to the IPv4 BitTorrent peer. > BitTorrent > clients do not perform this function today. > > I agree with that, but suppose you upgrade the bittorrent to do this > (which probably will happen if more content is available in IPv6) The need for such functionality in BitTorrent does not get created when more content is available in IPv6. Rather, the need occurs when an IPv6-only BitTorrent client wants to access content that is only available on an IPv4-only BitTorrent peer. > Which would be easier to handle, the well known prefix or the > lir prefix? > > With the well known prefix, the the bittorrent client could simply > hardcode the well know prefix and if it detects it is on an ipv6 only > host, it can prepend the well know prefix and it may work. > With the LIR > prefix, the bittorrent client would need to learn the nat64 prefix in > order to make any attempt at all. > > makes sense? I will, of course, concede it is easier to hard-code a prefix than do a DNS query. But learning the prefix is merely a DNS query (or DHCPINFORM, if you prefer), as detailed in which I updated today. BitTorrent clients are already pretty complex it seems reasonable to add a DNS query during the initialization of the BitTorrent client, especially if doing that DNS query allows an IPv6-only BitTorrent client to access content available on IPv4-only peers -- accessing content from peers is the primary purpose of a BitTorrent client. But the argument between well-known prefix and LIR prefix is not solely around which one is easier for an application. There are other considerations. -d From petithug@acm.org Mon Mar 9 11:58: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 388483A6AEF for ; Mon, 9 Mar 2009 11:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.215 X-Spam-Level: X-Spam-Status: No, score=-102.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP2-ShWh6vW3 for ; Mon, 9 Mar 2009 11:58:58 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 73C713A6C74 for ; Mon, 9 Mar 2009 11:58:10 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 4A0A7DBD40CE; Mon, 9 Mar 2009 18:58:44 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTP id 7B637DBD40C8; Mon, 9 Mar 2009 18:58:40 +0000 (UTC) Message-ID: <49B566DD.3010609@acm.org> Date: Mon, 09 Mar 2009 11:58:37 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Dan Wing References: <20090304194502.13A203A6830@core3.amsl.com><49AEDCA0.2070602@viagenie.ca> <49AEE6C4.6080909@acm.org> <0adc01c99d14$41bfded0$c2f0200a@cisco.com> In-Reply-To: <0adc01c99d14$41bfded0$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] draft-petithuguenin-turn-tcp-variant-00.txt [was RE: I-D Action:draft-ietf-behave-turn-tcp-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, 09 Mar 2009 18:58:59 -0000 Dan Wing wrote: >> One missing open issue is multiple connections vs shared connection >> (ala SSH). As far as I can read in the minutes of the Minneapolis >> meeting and the subsequent discussions in the mailing-list, nothing >> was decided. > > For everyone else's reference, here are pointers to the mailing list > discussion of your proposal, > draft-petithuguenin-turn-tcp-variant-00.txt: > > your announcement of the I-D: > http://www.ietf.org/mail-archive/web/behave/current/msg04938.html > > Rémi Denis-Courmont's comments: > http://www.ietf.org/mail-archive/web/behave/current/msg04942.html > > Simon Perreault's comments: > http://www.ietf.org/mail-archive/web/behave/current/msg04939.html > > your followup: > http://www.ietf.org/mail-archive/web/behave/current/msg04952.html > where you wrote: > > > > > Some of your arguments are absolutely true (HOLB), some are > > debatable, and the others I have to think about them. > > > > But there is also some advantages to the single connection > > solution, for example establishing a new peer TCP connection is > > faster. Please also have a look to section 3.3.2 in the excellent > > draft-iab-ip-model-evolution. > > > > Please followup to Remi's comments in this thread. > I submitted a new version of the turn-tcp-variant draft: http://www.ietf.org/internet-drafts/draft-petithuguenin-turn-tcp-variant-01.txt I put Remi's arguments inside the document as reasons not to adopt this variant in TURN TCP. I also added arguments in favors of adopting it :-) Comments are welcome. Thanks. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From root@core3.amsl.com Mon Mar 9 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 882183A682E; Mon, 9 Mar 2009 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309193001.882183A682E@core3.amsl.com> Date: Mon, 9 Mar 2009 12:30:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-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: Mon, 09 Mar 2009 19:30: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 : Traversal Using Relays around NAT (TURN) Extension for IPv6 Author(s) : G. Camarillo, O. Novo Filename : draft-ietf-behave-turn-ipv6-06.txt Pages : 12 Date : 2009-03-09 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-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-turn-ipv6-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09121600.I-D@ietf.org> --NextPart-- From marcelo@it.uc3m.es Mon Mar 9 13:06: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 48ED93A693C for ; Mon, 9 Mar 2009 13:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 s6n5ub64x0tC for ; Mon, 9 Mar 2009 13:06:03 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0E80D3A68D6 for ; Mon, 9 Mar 2009 13:06:03 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (117.pool85-53-145.dynamic.orange.es [85.53.145.117]) by smtp02.uc3m.es (Postfix) with ESMTP id 8AE966B6C8C; Mon, 9 Mar 2009 21:06:35 +0100 (CET) Message-ID: <49B576CB.8020906@it.uc3m.es> Date: Mon, 09 Mar 2009 21:06:35 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dan Wing References: <49B3909F.2050309@it.uc3m.es> <071a01c9a0e8$d1972450$c2f0200a@cisco.com> In-Reply-To: <071a01c9a0e8$d1972450$c2f0200a@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-5.6.0.1016-16510.001 Cc: 'Behave WG' Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Mon, 09 Mar 2009 20:06:04 -0000 Dan Wing escribió: >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Sunday, March 08, 2009 1:32 AM >> To: Dan Wing; Behave WG >> Subject: comment about draft-wing-behave-nat64-referrals-00.txt >> >> Hi, >> >> been through this document and i have a comment: >> >> >> section 2.2. BitTorrent reads >> >> BitTorrent trackers use HTTP URIs and DNS names. Thus, if an IPv6- >> only host running a web browser can connect to an >> IPv4-only web site >> using a translator (e.g., using NAT64 and DNS64), that >> same IPv6-only >> host running a BitTorrent client can connect to an IPv4-only >> BitTorrent tracker. While some BitTorrent trackers are >> beginning to >> track IPv6 addresses of BitTorrent peers, most trackers only track >> IPv4 peers. Most content is only available on IPv4. >> >> When an IPv6-only BitTorrent peer obtains IPv4 addresses from its >> tracker, it cannot use those IPv4 addresses. To do so, the >> BitTorrent client software would need to prefix the IPv4 >> address with >> the prefix of a NAT64 that will perform the necessary >> address family >> translation on behalf of the IPv6-only BitTorrent client. >> This could >> be done with updates to BitTorrent clients to prefix the >> IPv4 address >> with the IPv6 prefix of a NAT64 translator which will both >> authorize >> and route the communication to the IPv4 BitTorrent peer. >> BitTorrent >> clients do not perform this function today. >> >> I agree with that, but suppose you upgrade the bittorrent to do this >> (which probably will happen if more content is available in IPv6) >> > > The need for such functionality in BitTorrent does not get created > when more content is available in IPv6. Rather, the need occurs > when an IPv6-only BitTorrent client wants to access content that > is only available on an IPv4-only BitTorrent peer. > > >> Which would be easier to handle, the well known prefix or the >> lir prefix? >> >> With the well known prefix, the the bittorrent client could simply >> hardcode the well know prefix and if it detects it is on an ipv6 only >> host, it can prepend the well know prefix and it may work. >> With the LIR >> prefix, the bittorrent client would need to learn the nat64 prefix in >> order to make any attempt at all. >> >> makes sense? >> > > I will, of course, concede it is easier to hard-code a prefix than do a DNS > query. > > But learning the prefix is merely a DNS query (or DHCPINFORM, if you prefer), > as detailed in > which I updated today. BitTorrent clients are already pretty complex it seems > reasonable to add a DNS query during the initialization of the BitTorrent > client, especially if doing that DNS query allows an IPv6-only BitTorrent > client to access content available on IPv4-only peers -- accessing content > from peers is the primary purpose of a BitTorrent client. > > agree moreover, in any case, both with WK and the LIR prefix, the BT needs to be updated (it would be very different if with one of the options existent clients could work, but unfortunatelly, it is not the case) SO, i agree that if the BT client needs to be upated, either hardcofing the wk prefix or learning dynamically, doesn't change much > But the argument between well-known prefix and LIR prefix is not solely around > which one is easier for an application. There are other considerations. > > agree but the draft was discussing this one, hence the limited scope of this particular thread regards, marcelo > -d > > > From dwing@cisco.com Mon Mar 9 13:15: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 A27F23A69A8 for ; Mon, 9 Mar 2009 13:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 8Bizd21Qnyw7 for ; Mon, 9 Mar 2009 13:15:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8C4213A6BB0 for ; Mon, 9 Mar 2009 13:15:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,331,1233532800"; d="scan'208";a="264185470" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Mar 2009 20:16:32 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n29KGWsE012759; Mon, 9 Mar 2009 13:16:32 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n29KGVGk013279; Mon, 9 Mar 2009 20:16:31 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" , References: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> <49B4CC0F.5040304@it.uc3m.es> Date: Mon, 9 Mar 2009 13:16:31 -0700 Message-ID: <07f401c9a0f3$eff5cbd0$c2f0200a@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: <49B4CC0F.5040304@it.uc3m.es> Thread-Index: AcmgjMlO9PDhaocZQQC19mPmD53vEwAZYpkw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6109; t=1236629792; x=1237493792; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20comment=20about=20draft-wing -behave-nat64-referrals-00.txt |Sender:=20; bh=Sg8dHFtE4CDkrEKj8NkTs7F8ZfuiSU0nwYt4ar1YWJI=; b=NznaoYHshrWzIiPk5bDYIaQuug/WuNKOUS8nUKelq8y/BP0+S26C+KC6Ma jJ/xgGLunXMCQgAg3n2ScmI3vfgqZ4y2gGx/mhYBPlAX+j1BWLC6N7pWd+L6 6FLZ7IlMf7; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Mon, 09 Mar 2009 20:15:58 -0000 =20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Monday, March 09, 2009 12:58 AM > To: mohamed.boucadair@orange-ftgroup.com > Cc: dwing@cisco.com; behave@ietf.org > Subject: Re: [BEHAVE] comment about=20 > draft-wing-behave-nat64-referrals-00.txt >=20 > mohamed.boucadair@orange-ftgroup.com escribi=F3: > > Please see inline. > > Cheers, > > Med=20 > > > > > > -----Message d'origine----- > > De : behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] De la part de marcelo bagnulo braun > > Envoy=E9 : dimanche 8 mars 2009 10:32 > > =C0 : Dan Wing; Behave WG > > Objet : [BEHAVE] comment about=20 > draft-wing-behave-nat64-referrals-00.txt > > > > Hi, > > > > been through this document and i have a comment: > > > > > > section 2.2. BitTorrent reads > > > > BitTorrent trackers use HTTP URIs and DNS names. Thus,=20 > if an IPv6- > > only host running a web browser can connect to an=20 > IPv4-only web site > > using a translator (e.g., using NAT64 and DNS64), that=20 > same IPv6-only > > host running a BitTorrent client can connect to an IPv4-only > > BitTorrent tracker. While some BitTorrent trackers are=20 > beginning to > > track IPv6 addresses of BitTorrent peers, most trackers=20 > only track > > IPv4 peers. Most content is only available on IPv4. > > > > When an IPv6-only BitTorrent peer obtains IPv4 addresses from its > > tracker, it cannot use those IPv4 addresses. To do so, the > > BitTorrent client software would need to prefix the IPv4=20 > address with > > the prefix of a NAT64 that will perform the necessary=20 > address family > > translation on behalf of the IPv6-only BitTorrent=20 > client. This could > > be done with updates to BitTorrent clients to prefix the=20 > IPv4 address > > with the IPv6 prefix of a NAT64 translator which will=20 > both authorize > > and route the communication to the IPv4 BitTorrent peer.=20 > BitTorrent > > clients do not perform this function today. > > > > I agree with that, but suppose you upgrade the bittorrent=20 > to do this (which probably will happen if more content is=20 > available in IPv6) > > > > Which would be easier to handle, the well known prefix or=20 > the lir prefix? > > > > > > Med: for the application, it is easier to have a IANA=20 > assigned prefix.. > > > > > > With the well known prefix, the the bittorrent client could=20 > simply hardcode the well know prefix and if it detects it is=20 > on an ipv6 only host, it can prepend the well know prefix and=20 > it may work. With the LIR prefix, the bittorrent client would=20 > need to learn the nat64 prefix in order to make any attempt at all. > > > > makes sense? > > > > > > Med: This assumes the availability of inter-domain routes=20 > to reach those WK prefixes... > > > > =20 > I don't think so > Please check draft-miyata-behave-prefix64-01.txt just posted, the=20 > section about referrals I just read it. =20 That section of the draft assumes that IPv6 hosts and their applications would always (and only?) be able to refer IPv6 addresses. This is not a necessary design. In fact, that design will fail when those = applications provide a referral to an IPv4 host. Being as almost every SIP user agent and almost every BitTorrent peer are, today, on IPv4, this would be a poor design decision for those applications when the application is deployed on an IPv6-only host. draft-miyata-behave-prefix64-01 has the following diagram: | Host_A ---(ISP_A)---NAT64--\ | | >---Host_B (IPB) Host_C ---(ISP_B)---NAT64--/ | | IPv6 Internet | IPv4 Internet Figure: Referral scenario #2 involving multiple NAT64 boxes So, in this case, Host A will be sending Host B's address to Host C as application data. Now, in the eyes of Host A, Host B's address is Pref64_1:IPB:suffix (the suffix is optional, depending on whether Pref64_1 is 96 bits long or shorter). The problem is that, before sending the referral to Host-C, Host-A=20 cannot know if Host-C is: 1. running IPv6 at all (and could use the IPv6 address), or if 2. dual-stack without a NAT64 (which is IETF's current recommend=20 practice), and able to use Host-B's IPv4 address directly, or if 3. dual-stack with a NAT44 and without a NAT64. Such a host would be=20 able to use Host-B's IPv4 address, but could not use the synthetic IPv6 address. In all three of those cases, Host-C could make good use of Host-B's=20 IPv4 address. The corollary is also true: in all three of those cases, the IPv6 address is useless (no matter if well-known prefix or LIR prefix) and the referral fails because communication cannot=20 be established. I think the difference in how draft-miyata-behave-prefix64 and=20 draft-wing-behave-nat64-referrals describe IPv6/IPv4 referrals=20 points out the underlying problem: the IETF has been too vague in guidance to applications for how referrals should work, and needs to provide such guidance. -d > The Well known prefix, is passed from one domain to another doamin in=20 > the referral. > Once it is received in the other domain, it is used. So, what=20 > is needed=20 > is that both the originator of the referral and that the=20 > receiver of the=20 > referral have translation services. But if they don't have=20 > translation=20 > services, the referral won't work in any case cause the IPv4=20 > only host=20 > is no reachable >=20 > (this is a bit tricky to describe in a few setneces, so i=20 > reccomend you=20 > to check the referral section in the draft) >=20 > Regards, marcelo >=20 >=20 > > regards, marcelo > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > =20 >=20 From marcelo@it.uc3m.es Mon Mar 9 13:25: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 1C7D73A69ED for ; Mon, 9 Mar 2009 13:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 AEhqjHwOG9Rd for ; Mon, 9 Mar 2009 13:25:56 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B1DE93A69A8 for ; Mon, 9 Mar 2009 13:25:55 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (117.pool85-53-145.dynamic.orange.es [85.53.145.117]) by smtp03.uc3m.es (Postfix) with ESMTP id 485537354C8; Mon, 9 Mar 2009 21:26:27 +0100 (CET) Message-ID: <49B57B72.2010207@it.uc3m.es> Date: Mon, 09 Mar 2009 21:26:26 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dan Wing References: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> <49B4CC0F.5040304@it.uc3m.es> <07f401c9a0f3$eff5cbd0$c2f0200a@cisco.com> In-Reply-To: <07f401c9a0f3$eff5cbd0$c2f0200a@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-5.6.0.1016-16506.000 Cc: behave@ietf.org, mohamed.boucadair@orange-ftgroup.com Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Mon, 09 Mar 2009 20:25:57 -0000 Dan Wing escribió: > > > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Monday, March 09, 2009 12:58 AM >> To: mohamed.boucadair@orange-ftgroup.com >> Cc: dwing@cisco.com; behave@ietf.org >> Subject: Re: [BEHAVE] comment about >> draft-wing-behave-nat64-referrals-00.txt >> >> mohamed.boucadair@orange-ftgroup.com escribió: >> >>> Please see inline. >>> Cheers, >>> Med >>> >>> >>> -----Message d'origine----- >>> De : behave-bounces@ietf.org >>> >> [mailto:behave-bounces@ietf.org] De la part de marcelo bagnulo braun >> >>> Envoyé : dimanche 8 mars 2009 10:32 >>> Ŕ : Dan Wing; Behave WG >>> Objet : [BEHAVE] comment about >>> >> draft-wing-behave-nat64-referrals-00.txt >> >>> Hi, >>> >>> been through this document and i have a comment: >>> >>> >>> section 2.2. BitTorrent reads >>> >>> BitTorrent trackers use HTTP URIs and DNS names. Thus, >>> >> if an IPv6- >> >>> only host running a web browser can connect to an >>> >> IPv4-only web site >> >>> using a translator (e.g., using NAT64 and DNS64), that >>> >> same IPv6-only >> >>> host running a BitTorrent client can connect to an IPv4-only >>> BitTorrent tracker. While some BitTorrent trackers are >>> >> beginning to >> >>> track IPv6 addresses of BitTorrent peers, most trackers >>> >> only track >> >>> IPv4 peers. Most content is only available on IPv4. >>> >>> When an IPv6-only BitTorrent peer obtains IPv4 addresses from its >>> tracker, it cannot use those IPv4 addresses. To do so, the >>> BitTorrent client software would need to prefix the IPv4 >>> >> address with >> >>> the prefix of a NAT64 that will perform the necessary >>> >> address family >> >>> translation on behalf of the IPv6-only BitTorrent >>> >> client. This could >> >>> be done with updates to BitTorrent clients to prefix the >>> >> IPv4 address >> >>> with the IPv6 prefix of a NAT64 translator which will >>> >> both authorize >> >>> and route the communication to the IPv4 BitTorrent peer. >>> >> BitTorrent >> >>> clients do not perform this function today. >>> >>> I agree with that, but suppose you upgrade the bittorrent >>> >> to do this (which probably will happen if more content is >> available in IPv6) >> >>> Which would be easier to handle, the well known prefix or >>> >> the lir prefix? >> >>> Med: for the application, it is easier to have a IANA >>> >> assigned prefix.. >> >>> With the well known prefix, the the bittorrent client could >>> >> simply hardcode the well know prefix and if it detects it is >> on an ipv6 only host, it can prepend the well know prefix and >> it may work. With the LIR prefix, the bittorrent client would >> need to learn the nat64 prefix in order to make any attempt at all. >> >>> makes sense? >>> >>> >>> Med: This assumes the availability of inter-domain routes >>> >> to reach those WK prefixes... >> >>> >>> >> I don't think so >> Please check draft-miyata-behave-prefix64-01.txt just posted, the >> section about referrals >> > > I just read it. > > That section of the draft assumes that IPv6 hosts and their applications > would always (and only?) be able to refer IPv6 addresses. This is not > a necessary design. In fact, that design will fail when those applications > provide a referral to an IPv4 host. Being as almost every SIP user > agent and almost every BitTorrent peer are, today, on IPv4, this would > be a poor design decision for those applications when the application > is deployed on an IPv6-only host. > > > right Jari made this point and i have reflected this in a new version that i have submitted today (sorry about that) It is already available in the repositories > draft-miyata-behave-prefix64-01 has the following diagram: > > > | > Host_A ---(ISP_A)---NAT64--\ > | | >---Host_B (IPB) > Host_C ---(ISP_B)---NAT64--/ > | > | > IPv6 Internet | IPv4 Internet > > Figure: Referral scenario #2 involving multiple NAT64 boxes > > So, in this case, Host A will be sending Host B's address to Host C > as application data. Now, in the eyes of Host A, Host B's address is > Pref64_1:IPB:suffix (the suffix is optional, depending on whether > Pref64_1 is 96 bits long or shorter). > > The problem is that, before sending the referral to Host-C, Host-A > cannot know if Host-C is: > > 1. running IPv6 at all (and could use the IPv6 address), or if > 2. dual-stack without a NAT64 (which is IETF's current recommend > practice), and able to use Host-B's IPv4 address directly, or if > 3. dual-stack with a NAT44 and without a NAT64. Such a host would be > able to use Host-B's IPv4 address, but could not use the synthetic > IPv6 address. > > In all three of those cases, Host-C could make good use of Host-B's > IPv4 address. The corollary is also true: in all three of those > cases, the IPv6 address is useless (no matter if well-known prefix > or LIR prefix) and the referral fails because communication cannot > be established. > > > I think i agree. Host A can either send the IPv4 address or the IPv6 representation of the IPv4 address. If it sends that IPv6 representation of the address, the WK prefix could help, cause the other end could recognize it as such If it sends the IPv4 address directly, then, it would also make sense for the receiving host, since it understnads IPv4 Now, maybe the most reasonable approach when referring an IPv4 address is to pass it directly and not to pass the IPv6 representation, even if the sender is an IPv6 only host. I can buy that. But wouldn't this assuming that apps will continue to support IPv4? this is certainly a reasonable assumption to make at this point, but will this hold in the future? regards, marcelo > I think the difference in how draft-miyata-behave-prefix64 and > draft-wing-behave-nat64-referrals describe IPv6/IPv4 referrals > points out the underlying problem: the IETF has been too vague in > guidance to applications for how referrals should work, and needs > to provide such guidance. > > -d > > > >> The Well known prefix, is passed from one domain to another doamin in >> the referral. >> Once it is received in the other domain, it is used. So, what >> is needed >> is that both the originator of the referral and that the >> receiver of the >> referral have translation services. But if they don't have >> translation >> services, the referral won't work in any case cause the IPv4 >> only host >> is no reachable >> >> (this is a bit tricky to describe in a few setneces, so i >> reccomend you >> to check the referral section in the draft) >> >> Regards, marcelo >> >> >> >>> regards, marcelo >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >>> > > > From aeh@db.org Mon Mar 9 13:59: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 642E53A69DE for ; Mon, 9 Mar 2009 13:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMeiTg1FqHDo for ; Mon, 9 Mar 2009 13:59:12 -0700 (PDT) Received: from submit-tmp.sysedata.no (submit-tmp.sysedata.no [195.159.29.133]) by core3.amsl.com (Postfix) with ESMTP id 7C5013A6B76 for ; Mon, 9 Mar 2009 13:59:12 -0700 (PDT) Received: from [84.215.77.175] (helo=[10.0.0.30]) by submit-tmp.sysedata.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LgmZc-0005sD-8t for behave@ietf.org; Mon, 09 Mar 2009 21:59:44 +0100 Message-ID: <49B5833F.4080600@db.org> Date: Mon, 09 Mar 2009 21:59:43 +0100 From: "Alfred E. Heggestad" User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: behave@ietf.org References: <20090309193001.882183A682E@core3.amsl.com> In-Reply-To: <20090309193001.882183A682E@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-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: Mon, 09 Mar 2009 20:59:13 -0000 Hi I have a quick question regarding the new version: 6.2.1. Peer Address Family Mismatch This document defines the following new error response code: 443 (Peer Address Family Mismatch): A peer address was of a different address family than the relayed transport address of the allocation. --> I think 443 should also be listed in Section 10.2. New STUN Response Code Registry /alfred 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 : Traversal Using Relays around NAT (TURN) Extension for IPv6 > Author(s) : G. Camarillo, O. Novo > Filename : draft-ietf-behave-turn-ipv6-06.txt > Pages : 12 > Date : 2009-03-09 > > 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-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Mon Mar 9 15:08: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 7B73B28C149 for ; Mon, 9 Mar 2009 15:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 yKWafU8HyuIQ for ; Mon, 9 Mar 2009 15:08:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B9D4B28C12E for ; Mon, 9 Mar 2009 15:08:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,332,1233532800"; d="scan'208";a="153153940" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 09 Mar 2009 22:09:14 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n29M9EZu002130; Mon, 9 Mar 2009 15:09:14 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n29M9E26003479; Mon, 9 Mar 2009 22:09:14 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" References: <49B3909F.2050309@it.uc3m.es><6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3><49B4CC0F.5040304@it.uc3m.es><07f401c9a0f3$eff5cbd0$c2f0200a@cisco.com> <49B57B72.2010207@it.uc3m.es> Date: Mon, 9 Mar 2009 15:09:14 -0700 Message-ID: <09ac01c9a103$aea0aff0$c2f0200a@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: <49B57B72.2010207@it.uc3m.es> Thread-Index: Acmg9Vde+dcYt/ybQDqjEpbQuWByPQADX31A DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1124; t=1236636554; x=1237500554; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20comment=20about=20draft-wing -behave-nat64-referrals-00.txt |Sender:=20; bh=MpE9eZtx+wuKIyWC+hJ0UXJhrbI90+TZvX5okRuhFMU=; b=RJtmDtb9ldptdOPKwHcvkXMbNQ7Tin71XzPjx1rjBLQgtluSo9iVc0eQ5u B8hh/zBxiuODcRG0L5P3iTiNn8sHY8HoFJoxdKEPtM1CSLWR1p73BfSOJHsO gVoncFEUO8; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mohamed.boucadair@orange-ftgroup.com, behave@ietf.org Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Mon, 09 Mar 2009 22:08:40 -0000 > Now, maybe the most reasonable approach when referring an > IPv4 address > is to pass it directly and not to pass the IPv6 > representation, even if > the sender is an IPv6 only host. I can buy that. But wouldn't this > assuming that apps will continue to support IPv4? this is certainly a > reasonable assumption to make at this point, but will this > hold in the future? It's only important so long as there is an IPv6/IPv4 translation device and a need for IPv6 hosts to communicate across the translator to an IPv4 device. Once the IPv6 transition is complete, these devices would be removed and the IPv4-aware code in IPv6 BitTorrent clients and in IPv6 SIP clients can be removed. This appears to impact only SIP and BitTorrent. If IPv6 gives birth to a killer IPv6 application which does referrals, that killer application will not need to interact with IPv4 nodes and will not need a NAT64. So I don't forsee a future where we are 'stuck' with needing to understand IPv4 referrals when, in the future, someone invents an IPv6 application that performs IPv6 referrals. -d From huitema@windows.microsoft.com Mon Mar 9 17:12: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 EDE9E3A6CB3; Mon, 9 Mar 2009 17:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QIRfzFAvk7o; Mon, 9 Mar 2009 17:12:10 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 366773A6938; Mon, 9 Mar 2009 17:12:10 -0700 (PDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 9 Mar 2009 17:12:38 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.2.99.4; Mon, 9 Mar 2009 17:12:38 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Mon, 9 Mar 2009 17:14:45 -0700 From: Christian Huitema To: "Internet-Drafts@ietf.org" , "i-d-announce@ietf.org" Date: Mon, 9 Mar 2009 17:12:34 -0700 Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-06.txt Thread-Index: Acmg7howLey6t+CrRj21Zj5jbBiuxQAJd0NA Message-ID: <8EFB68EAE061884A8517F2A755E8B60A1CB2F34917@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <20090309193001.882183A682E@core3.amsl.com> In-Reply-To: <20090309193001.882183A682E@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-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: Tue, 10 Mar 2009 00:12:11 -0000 > 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). I really wish that the document be much more clear in the introduction with= what it means by "relaying". I read the following paragraph: A TURN server that supports a set of address families is assumed to be able to relay packets between them. If a server does not support the address family requested by a client, the server returns a 440 (Address Family not Supported) error response. What does "relay .. between them" mean there? Do we mean: "a TURN server t= hat supports a set of address families can receive request to allocate port= s for either family. It is assumed that the server that allocate a port for= a particular family can relay the received packets to the client, even if = the connection between server and client is established using a different a= ddress family. For example, an IPv6 client may contact the TURN server usin= g IPv6, request allocation of an IPv4 port, and then send and receive packe= ts to and from IPv4 destinations using TURN messages carried over the IPv6 = connection"? -- Christian Huitema From pierre.levis@orange-ftgroup.com Tue Mar 10 01:21: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 4BD073A6837 for ; Tue, 10 Mar 2009 01:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_75=0.6, 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 oostO-FYDVQP for ; Tue, 10 Mar 2009 01:21:07 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 0A9623A6857 for ; Tue, 10 Mar 2009 01:21:06 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 09:21:30 +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: Tue, 10 Mar 2009 09:21:29 +0100 Message-ID: In-Reply-To: <49B4E949.3040601@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-02.txt] Thread-Index: AcmgnjkSdga6PG/cRoqRWFOFtIzAMQAtml/Q References: <49B4E949.3040601@it.uc3m.es> From: To: , , X-OriginalArrivalTime: 10 Mar 2009 08:21:30.0196 (UTC) FILETIME=[36E5C940:01C9A159] Subject: Re: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-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: Tue, 10 Mar 2009 08:21:08 -0000 Dear authors, Thank you for this draft. Some quite generic comments: Do you think the scope of this document can be enlarged, keeping the = focus on how to choose Prefix64?=20 I'm thinking of some IPv4 into IPv6 encapsulation scenarios (and not = only translation scenarios).=20 In these scenarios you build the IPv6 destination address of the IPv6 = packet that will encapsulate an IPv4 packet, based only on the = information of the IPv4 packet (mainly A+P). The encapsulation is then = stateless.=20 Typically, the IPv6 destination address has the generic format you = provide in Fig 2.1.=20 Examples can be found in I-D.boucadair-behave-ipv6-portrange and in = I-D.despres-sam-scenarios. In some cases, the IPv4 address may be represented differently as simply = the rough 32 bits. This is in order to force the total prefix length = (PREFIX64+IPv4 address+extra info) to stay within a given boundary (e.g. = /64). Space concern can be important when you need to put not only an = IPv4 address but also a port information in the IPv6 address. Example of = construction can be found in I-D.despres-sam. In the first Figure in section "5.1. IPv6 Routing system scalability": I don't see why, and how, the IPv4 site is connected to an IPv6 ISP, and = precisely to the very one that connects the IPv6 site it communicates = with? Regards, Pierre =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de marcelo bagnulo braun Envoy=E9 : lundi 9 mars 2009 11:03 =C0 : Behave WG Objet : [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-02.txt] I have submitted a new version of this one, cause i missed one set of=20 comments is received in the previous one sorry for the confusion regards, marcelo -------- Mensaje original -------- Asunto: I-D Action:draft-miyata-behave-prefix64-02.txt Fecha: Mon, 9 Mar 2009 02:45:02 -0700 (PDT) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : PREFIX64 Comparison Author(s) : H. Miyata, M. Bagnulo Filename : draft-miyata-behave-prefix64-02.txt Pages : 24 Date : 2009-03-09 This draft compares different IPv6 prefix formats that can be used by IPv6-IPv4 translator to represent IPv4 addresses in the IPv6 Internet. The goal of the draft is asses the benefits and problems of each proposed format and make a recommendation about which prefix to use in the different scenarios considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-miyata-behave-prefix64-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. From H.Miyata@jp.yokogawa.com Tue Mar 10 01:31: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 6F36C3A6CE8 for ; Tue, 10 Mar 2009 01:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.504 X-Spam-Level: * X-Spam-Status: No, score=1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_75=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaC4SmKoVuGj for ; Tue, 10 Mar 2009 01:31:56 -0700 (PDT) Received: from zns001-0m9001.yokogawa.co.jp (zns001-0m9001.yokogawa.co.jp [203.174.79.138]) by core3.amsl.com (Postfix) with ESMTP id 5648B3A6CE3 for ; Tue, 10 Mar 2009 01:31:56 -0700 (PDT) Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n2A8WOW5019180; Tue, 10 Mar 2009 17:32:24 +0900 (JST) Received: from zex001-0m9026.jp.ykgw.net (zex001-0m9026.p.ykgw.net [10.0.11.15] (may be forged)) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n2A8WNeE019135; Tue, 10 Mar 2009 17:32:23 +0900 (JST) Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9026.jp.ykgw.net ([10.0.11.45]) with mapi; Tue, 10 Mar 2009 17:32:21 +0900 From: To: , , Date: Tue, 10 Mar 2009 17:32:20 +0900 Thread-Topic: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-02.txt] Thread-Index: AcmgnjkSdga6PG/cRoqRWFOFtIzAMQAtml/QAAFbwYA= Message-ID: References: <49B4E949.3040601@it.uc3m.es> In-Reply-To: Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-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: Tue, 10 Mar 2009 08:31:57 -0000 Hi Pierre, Thanks for your comments and proposal. This is very quick reply to your first proposal. Unfortunately, I think the work should be proceeded separately. Sinced the context is different, the analysis should be different. It eventually accelerate the discussion. Regards, ------------------------------------ Hiroshi Miyata, Ubiquitous Field Computing Research Center, Corporate R&D Headquaters, Yokogawa Electric Corp. =20 > -----Original Message----- > From: pierre.levis@orange-ftgroup.com=20 > [mailto:pierre.levis@orange-ftgroup.com]=20 > Sent: Tuesday, March 10, 2009 5:21 PM > To: marcelo@it.uc3m.es; behave@ietf.org; Miyata, Hiroshi=20 > (H.Miyata@jp.yokogawa.com) > Subject: RE: [BEHAVE] [Fwd: I-D=20 > Action:draft-miyata-behave-prefix64-02.txt] >=20 > Dear authors, >=20 > Thank you for this draft. >=20 > Some quite generic comments: >=20 > Do you think the scope of this document can be enlarged,=20 > keeping the focus on how to choose Prefix64?=20 > I'm thinking of some IPv4 into IPv6 encapsulation scenarios=20 > (and not only translation scenarios).=20 > In these scenarios you build the IPv6 destination address of=20 > the IPv6 packet that will encapsulate an IPv4 packet, based=20 > only on the information of the IPv4 packet (mainly A+P). The=20 > encapsulation is then stateless.=20 > Typically, the IPv6 destination address has the generic=20 > format you provide in Fig 2.1.=20 > Examples can be found in I-D.boucadair-behave-ipv6-portrange=20 > and in I-D.despres-sam-scenarios. >=20 > In some cases, the IPv4 address may be represented=20 > differently as simply the rough 32 bits. This is in order to=20 > force the total prefix length (PREFIX64+IPv4 address+extra=20 > info) to stay within a given boundary (e.g. /64). Space=20 > concern can be important when you need to put not only an=20 > IPv4 address but also a port information in the IPv6 address.=20 > Example of construction can be found in I-D.despres-sam. >=20 > In the first Figure in section "5.1. IPv6 Routing system=20 > scalability": > I don't see why, and how, the IPv4 site is connected to an=20 > IPv6 ISP, and precisely to the very one that connects the=20 > IPv6 site it communicates with? >=20 >=20 > Regards, >=20 > Pierre > =20 >=20 > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org]=20 > De la part de marcelo bagnulo braun Envoy=E9 : lundi 9 mars=20 > 2009 11:03 =C0 : Behave WG Objet : [BEHAVE] [Fwd: I-D=20 > Action:draft-miyata-behave-prefix64-02.txt] >=20 > I have submitted a new version of this one, cause i missed=20 > one set of comments is received in the previous one >=20 > sorry for the confusion >=20 > regards, marcelo >=20 >=20 > -------- Mensaje original -------- > Asunto: I-D Action:draft-miyata-behave-prefix64-02.txt > Fecha: Mon, 9 Mar 2009 02:45:02 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org >=20 >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : PREFIX64 Comparison > Author(s) : H. Miyata, M. Bagnulo > Filename : draft-miyata-behave-prefix64-02.txt > Pages : 24 > Date : 2009-03-09 >=20 > This draft compares different IPv6 prefix formats that can be used by > IPv6-IPv4 translator to represent IPv4 addresses in the IPv6=20 > Internet. The goal of the draft is asses the benefits and=20 > problems of each proposed format and make a recommendation=20 > about which prefix to use in the different scenarios considered. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-miyata-behave-prefix > 64-02.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=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 >=20 > = From pierre.levis@orange-ftgroup.com Tue Mar 10 02:08: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 0CEF33A6A9D for ; Tue, 10 Mar 2009 02:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_75=0.6, 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 Atq66cY9T8Jj for ; Tue, 10 Mar 2009 02:08:29 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 781D33A69C7 for ; Tue, 10 Mar 2009 02:08:29 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 10:08:51 +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: Tue, 10 Mar 2009 10:08:49 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-02.txt] Thread-Index: AcmgnjkSdga6PG/cRoqRWFOFtIzAMQAtml/QAAFbwYAAAMFZoA== References: <49B4E949.3040601@it.uc3m.es> From: To: , , X-OriginalArrivalTime: 10 Mar 2009 09:08:51.0081 (UTC) FILETIME=[D4326F90:01C9A15F] Subject: Re: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-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: Tue, 10 Mar 2009 09:08:31 -0000 Well, as far as Prefix64 is concerned, I don't think the two contexts = and analyses would be that different. How you retrieve, know, which Prefix64 to select, seems quite = independent on what the packet bears. Once the IPv6 packet is formed, whether it carries an IPv4 packet or a = TCP segment (or whatsoever), the routing issues apply in the same way. Pierre -----Message d'origine----- De : H.Miyata@jp.yokogawa.com [mailto:H.Miyata@jp.yokogawa.com]=20 Envoy=E9 : mardi 10 mars 2009 09:32 =C0 : LEVIS Pierre RD-CORE-CAE; marcelo@it.uc3m.es; behave@ietf.org Objet : RE: [BEHAVE] [Fwd: I-D = Action:draft-miyata-behave-prefix64-02.txt] Hi Pierre, Thanks for your comments and proposal. This is very quick reply to your first proposal. Unfortunately, I think the work should be proceeded separately. Sinced the context is different, the analysis should be different. It eventually accelerate the discussion. Regards, ------------------------------------ Hiroshi Miyata, Ubiquitous Field Computing Research Center, Corporate R&D Headquaters, Yokogawa Electric Corp. =20 > -----Original Message----- > From: pierre.levis@orange-ftgroup.com=20 > [mailto:pierre.levis@orange-ftgroup.com]=20 > Sent: Tuesday, March 10, 2009 5:21 PM > To: marcelo@it.uc3m.es; behave@ietf.org; Miyata, Hiroshi=20 > (H.Miyata@jp.yokogawa.com) > Subject: RE: [BEHAVE] [Fwd: I-D=20 > Action:draft-miyata-behave-prefix64-02.txt] >=20 > Dear authors, >=20 > Thank you for this draft. >=20 > Some quite generic comments: >=20 > Do you think the scope of this document can be enlarged,=20 > keeping the focus on how to choose Prefix64?=20 > I'm thinking of some IPv4 into IPv6 encapsulation scenarios=20 > (and not only translation scenarios).=20 > In these scenarios you build the IPv6 destination address of=20 > the IPv6 packet that will encapsulate an IPv4 packet, based=20 > only on the information of the IPv4 packet (mainly A+P). The=20 > encapsulation is then stateless.=20 > Typically, the IPv6 destination address has the generic=20 > format you provide in Fig 2.1.=20 > Examples can be found in I-D.boucadair-behave-ipv6-portrange=20 > and in I-D.despres-sam-scenarios. >=20 > In some cases, the IPv4 address may be represented=20 > differently as simply the rough 32 bits. This is in order to=20 > force the total prefix length (PREFIX64+IPv4 address+extra=20 > info) to stay within a given boundary (e.g. /64). Space=20 > concern can be important when you need to put not only an=20 > IPv4 address but also a port information in the IPv6 address.=20 > Example of construction can be found in I-D.despres-sam. >=20 > In the first Figure in section "5.1. IPv6 Routing system=20 > scalability": > I don't see why, and how, the IPv4 site is connected to an=20 > IPv6 ISP, and precisely to the very one that connects the=20 > IPv6 site it communicates with? >=20 >=20 > Regards, >=20 > Pierre > =20 >=20 > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org]=20 > De la part de marcelo bagnulo braun Envoy=E9 : lundi 9 mars=20 > 2009 11:03 =C0 : Behave WG Objet : [BEHAVE] [Fwd: I-D=20 > Action:draft-miyata-behave-prefix64-02.txt] >=20 > I have submitted a new version of this one, cause i missed=20 > one set of comments is received in the previous one >=20 > sorry for the confusion >=20 > regards, marcelo >=20 >=20 > -------- Mensaje original -------- > Asunto: I-D Action:draft-miyata-behave-prefix64-02.txt > Fecha: Mon, 9 Mar 2009 02:45:02 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org >=20 >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : PREFIX64 Comparison > Author(s) : H. Miyata, M. Bagnulo > Filename : draft-miyata-behave-prefix64-02.txt > Pages : 24 > Date : 2009-03-09 >=20 > This draft compares different IPv6 prefix formats that can be used by > IPv6-IPv4 translator to represent IPv4 addresses in the IPv6=20 > Internet. The goal of the draft is asses the benefits and=20 > problems of each proposed format and make a recommendation=20 > about which prefix to use in the different scenarios considered. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-miyata-behave-prefix > 64-02.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=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 >=20 >=20 From magnus.westerlund@ericsson.com Tue Mar 10 02:46: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 6E1103A69A8 for ; Tue, 10 Mar 2009 02:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_SE=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 UV0zfoKI3uIa for ; Tue, 10 Mar 2009 02:46:32 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 66C523A6920 for ; Tue, 10 Mar 2009 02:46:32 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3BD1E20A0E; Tue, 10 Mar 2009 10:47:06 +0100 (CET) X-AuditID: c1b4fb3c-af00dbb000001b43-7d-49b6371a3a2d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1F88820535; Tue, 10 Mar 2009 10:47:06 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 10:47:05 +0100 Received: from [147.214.183.107] ([147.214.183.107]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 10:47:05 +0100 Message-ID: <49B63719.6010208@ericsson.com> Date: Tue, 10 Mar 2009 10:47:05 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Bruce Lowekamp References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 10 Mar 2009 09:47:05.0605 (UTC) FILETIME=[2BD70350:01C9A165] X-Brightmail-Tracker: AAAAAA== Cc: behave Mailing List Subject: Re: [BEHAVE] draft-ietf-behave-nat-behavior-discovery-06 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: Tue, 10 Mar 2009 09:46:33 -0000 Bruce Lowekamp skrev: > -06 of nat-behavior discovery has been posted. Changes in this > revision are fairly minimal to address comments received. > > from draft-ietf-behave-nat-behavior-discovery-05 > > * In applicability section, add explicit requirement that citing > drafts must specify how they handle failure > * Add new subsection on selecting the source port used for tests, > covering both requirements that the same port be used for tests as for > the application and dependencies on previous bindings. Reference that > section explicitly for tests that are sensitive to previous binding > state. > * Change SRV discovery to stun-behavior for UDP and TCP and > stun-behaviors for TLS/TCP. > * Add SRV registry subsection to IANA section. Hi Bruce, It seems that you failed to address a number of issues from my AD comments. Can you please motivate, or was this simply forgotten. cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From marcelo@it.uc3m.es Tue Mar 10 03:10: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 E4E733A6A99 for ; Tue, 10 Mar 2009 03:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.046, 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 cRazripnYBAs for ; Tue, 10 Mar 2009 03:10:00 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 13DF93A6A5F for ; Tue, 10 Mar 2009 03:10:00 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (131.pool85-53-143.dynamic.orange.es [85.53.143.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 3BC39B4978A; Tue, 10 Mar 2009 11:10:32 +0100 (CET) Message-ID: <49B63C97.5080006@it.uc3m.es> Date: Tue, 10 Mar 2009 11:10:31 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dan Wing References: <49B3909F.2050309@it.uc3m.es><6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3><49B4CC0F.5040304@it.uc3m.es><07f401c9a0f3$eff5cbd0$c2f0200a@cisco.com> <49B57B72.2010207@it.uc3m.es> <09ac01c9a103$aea0aff0$c2f0200a@cisco.com> In-Reply-To: <09ac01c9a103$aea0aff0$c2f0200a@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-5.6.0.1016-16510.006 Cc: mohamed.boucadair@orange-ftgroup.com, behave@ietf.org Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Tue, 10 Mar 2009 10:10:01 -0000 Dan Wing escribió: >> Now, maybe the most reasonable approach when referring an >> IPv4 address >> is to pass it directly and not to pass the IPv6 >> representation, even if >> the sender is an IPv6 only host. I can buy that. But wouldn't this >> assuming that apps will continue to support IPv4? this is certainly a >> reasonable assumption to make at this point, but will this >> hold in the future? >> > > It's only important so long as there is an IPv6/IPv4 translation > device and a need for IPv6 hosts to communicate across the translator > to an IPv4 device. Once the IPv6 transition is complete, these devices > would be removed and the IPv4-aware code in IPv6 BitTorrent clients > and in IPv6 SIP clients can be removed. > > This appears to impact only SIP and BitTorrent. But there are millions of applications out that there that we don't don't know how they work For instance, what about multiplayer games? Don't they do referrals? (i ahve no idea, but it seems a sceanrio that is complex enough to may need this) My point is that while bitorrent and SIP are two celar cases, it is not obvious to me that they are the only ones Regards, marcelo > > > > If IPv6 gives birth to a killer IPv6 application which does referrals, > that killer application will not need to interact with IPv4 nodes and > will not need a NAT64. > So I don't forsee a future where we are 'stuck' > with needing to understand IPv4 referrals when, in the future, someone > invents an IPv6 application that performs IPv6 referrals. > > -d > > > From marcelo@it.uc3m.es Tue Mar 10 03:14: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 68C1D3A6CFA for ; Tue, 10 Mar 2009 03:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 8GzwM8hC1cXf for ; Tue, 10 Mar 2009 03:14:27 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CFE4C3A68F9 for ; Tue, 10 Mar 2009 03:14:26 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (131.pool85-53-143.dynamic.orange.es [85.53.143.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 30611656625; Tue, 10 Mar 2009 11:15:00 +0100 (CET) Message-ID: <49B63DA3.4000707@it.uc3m.es> Date: Tue, 10 Mar 2009 11:14:59 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dan Wing References: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> <49B4CC0F.5040304@it.uc3m.es> <07f401c9a0f3$eff5cbd0$c2f0200a@cisco.com> In-Reply-To: <07f401c9a0f3$eff5cbd0$c2f0200a@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-5.6.0.1016-16510.006 Cc: behave@ietf.org, mohamed.boucadair@orange-ftgroup.com Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Tue, 10 Mar 2009 10:14:28 -0000 Dan Wing escribió: > > > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Monday, March 09, 2009 12:58 AM >> To: mohamed.boucadair@orange-ftgroup.com >> Cc: dwing@cisco.com; behave@ietf.org >> Subject: Re: [BEHAVE] comment about >> draft-wing-behave-nat64-referrals-00.txt >> >> mohamed.boucadair@orange-ftgroup.com escribió: >> >>> Please see inline. >>> Cheers, >>> Med >>> >>> >>> -----Message d'origine----- >>> De : behave-bounces@ietf.org >>> >> [mailto:behave-bounces@ietf.org] De la part de marcelo bagnulo braun >> >>> Envoyé : dimanche 8 mars 2009 10:32 >>> Ŕ : Dan Wing; Behave WG >>> Objet : [BEHAVE] comment about >>> >> draft-wing-behave-nat64-referrals-00.txt >> >>> Hi, >>> >>> been through this document and i have a comment: >>> >>> >>> section 2.2. BitTorrent reads >>> >>> BitTorrent trackers use HTTP URIs and DNS names. Thus, >>> >> if an IPv6- >> >>> only host running a web browser can connect to an >>> >> IPv4-only web site >> >>> using a translator (e.g., using NAT64 and DNS64), that >>> >> same IPv6-only >> >>> host running a BitTorrent client can connect to an IPv4-only >>> BitTorrent tracker. While some BitTorrent trackers are >>> >> beginning to >> >>> track IPv6 addresses of BitTorrent peers, most trackers >>> >> only track >> >>> IPv4 peers. Most content is only available on IPv4. >>> >>> When an IPv6-only BitTorrent peer obtains IPv4 addresses from its >>> tracker, it cannot use those IPv4 addresses. To do so, the >>> BitTorrent client software would need to prefix the IPv4 >>> >> address with >> >>> the prefix of a NAT64 that will perform the necessary >>> >> address family >> >>> translation on behalf of the IPv6-only BitTorrent >>> >> client. This could >> >>> be done with updates to BitTorrent clients to prefix the >>> >> IPv4 address >> >>> with the IPv6 prefix of a NAT64 translator which will >>> >> both authorize >> >>> and route the communication to the IPv4 BitTorrent peer. >>> >> BitTorrent >> >>> clients do not perform this function today. >>> >>> I agree with that, but suppose you upgrade the bittorrent >>> >> to do this (which probably will happen if more content is >> available in IPv6) >> >>> Which would be easier to handle, the well known prefix or >>> >> the lir prefix? >> >>> Med: for the application, it is easier to have a IANA >>> >> assigned prefix.. >> >>> With the well known prefix, the the bittorrent client could >>> >> simply hardcode the well know prefix and if it detects it is >> on an ipv6 only host, it can prepend the well know prefix and >> it may work. With the LIR prefix, the bittorrent client would >> need to learn the nat64 prefix in order to make any attempt at all. >> >>> makes sense? >>> >>> >>> Med: This assumes the availability of inter-domain routes >>> >> to reach those WK prefixes... >> >>> >>> >> I don't think so >> Please check draft-miyata-behave-prefix64-01.txt just posted, the >> section about referrals >> > > I just read it. > > That section of the draft assumes that IPv6 hosts and their applications > would always (and only?) be able to refer IPv6 addresses. This is not > a necessary design. In fact, that design will fail when those applications > provide a referral to an IPv4 host. Being as almost every SIP user > agent and almost every BitTorrent peer are, today, on IPv4, this would > be a poor design decision for those applications when the application > is deployed on an IPv6-only host. > > > draft-miyata-behave-prefix64-01 has the following diagram: > > > | > Host_A ---(ISP_A)---NAT64--\ > | | >---Host_B (IPB) > Host_C ---(ISP_B)---NAT64--/ > | > | > IPv6 Internet | IPv4 Internet > > Figure: Referral scenario #2 involving multiple NAT64 boxes > > So, in this case, Host A will be sending Host B's address to Host C > as application data. Now, in the eyes of Host A, Host B's address is > Pref64_1:IPB:suffix (the suffix is optional, depending on whether > Pref64_1 is 96 bits long or shorter). > > The problem is that, before sending the referral to Host-C, Host-A > cannot know if Host-C is: > > 1. running IPv6 at all (and could use the IPv6 address), or if > 2. dual-stack without a NAT64 (which is IETF's current recommend > practice), and able to use Host-B's IPv4 address directly, or if > 3. dual-stack with a NAT44 and without a NAT64. Such a host would be > able to use Host-B's IPv4 address, but could not use the synthetic > IPv6 address. > > In all three of those cases, Host-C could make good use of Host-B's > IPv4 address. one more question about this... how does Host A knows that Pref64_1:IPB:suffix is indeed a representation of an IPv4 address in IPv6? In order to do that, it needs to know the prefix used for that again, we are int he situation that host A needs to discover the prefix64 in order to identify this is a represetnation of an IPv4 address in IPv6. So the host A would need to implement the discover provedures if the LIR prefix is used Regards, marcelo > The corollary is also true: in all three of those > cases, the IPv6 address is useless (no matter if well-known prefix > or LIR prefix) and the referral fails because communication cannot > be established. > > > I think the difference in how draft-miyata-behave-prefix64 and > draft-wing-behave-nat64-referrals describe IPv6/IPv4 referrals > points out the underlying problem: the IETF has been too vague in > guidance to applications for how referrals should work, and needs > to provide such guidance. > > -d > > > >> The Well known prefix, is passed from one domain to another doamin in >> the referral. >> Once it is received in the other domain, it is used. So, what >> is needed >> is that both the originator of the referral and that the >> receiver of the >> referral have translation services. But if they don't have >> translation >> services, the referral won't work in any case cause the IPv4 >> only host >> is no reachable >> >> (this is a bit tricky to describe in a few setneces, so i >> reccomend you >> to check the referral section in the draft) >> >> Regards, marcelo >> >> >> >>> regards, marcelo >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >>> > > > From bbl@lowekamp.net Tue Mar 10 03:21: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 EE7E83A6883 for ; Tue, 10 Mar 2009 03:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 Pu13dy0omts5 for ; Tue, 10 Mar 2009 03:21:43 -0700 (PDT) Received: from mail-qy0-f108.google.com (mail-qy0-f108.google.com [209.85.221.108]) by core3.amsl.com (Postfix) with ESMTP id EAC1D3A68FB for ; Tue, 10 Mar 2009 03:21:42 -0700 (PDT) Received: by qyk6 with SMTP id 6so1429921qyk.29 for ; Tue, 10 Mar 2009 03:22:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.82.12 with SMTP id z12mr3386509qck.59.1236680537599; Tue, 10 Mar 2009 03:22:17 -0700 (PDT) In-Reply-To: <49B63719.6010208@ericsson.com> References: <49B63719.6010208@ericsson.com> Date: Tue, 10 Mar 2009 06:22:17 -0400 Message-ID: From: Bruce Lowekamp To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: behave Mailing List Subject: Re: [BEHAVE] draft-ietf-behave-nat-behavior-discovery-06 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: Tue, 10 Mar 2009 10:21:44 -0000 Magnus, I believe that most of your comments were resolved in -05. The one remaining issue (which was introduced in -05) was resolved by the source port selection text being expanded and given its own subsection in -06. At least, that's what I have in my notes and my understanding from our email thread last November (unfortunate that it's been delayed so long). Please let me know if you believe there are other outstanding issues. Bruce Changelog from -05: A.6. from draft-ietf-behave-nat-behavior-discovery-04 o Clarified that behavior may vary by port used as well as by destination IP/particular STUN server, and therefore specified that all tests should be performed using the port the application will use o Added additional text on selecting random port/ensuring port has been unused prior to starting filtering tests o specified limit to start rate of tests and that tests retransmissions should not synchronize o additional explanatory text for XOR-RESPONSE-TARGET o added SRV entry to IANA section and subdivided to match STUN registries from 5389 o clarified that test combinations are non-normative o Numerous clarifications o Changed PADDING to default to interface MTU, and changed maximum length to not make IP datagram exceed 64K o Added text that server should allocate TCP and TCP/TLS On Tue, Mar 10, 2009 at 5:47 AM, Magnus Westerlund wrote: > Bruce Lowekamp skrev: >> -06 of nat-behavior discovery has been posted. =C2=A0Changes in this >> revision are fairly minimal to address comments received. >> >> from draft-ietf-behave-nat-behavior-discovery-05 >> >> =C2=A0 =C2=A0 * In applicability section, add explicit requirement that = citing >> drafts must specify how they handle failure >> =C2=A0 =C2=A0 * Add new subsection on selecting the source port used for= tests, >> covering both requirements that the same port be used for tests as for >> the application and dependencies on previous bindings. Reference that >> section explicitly for tests that are sensitive to previous binding >> state. >> =C2=A0 =C2=A0 * Change SRV discovery to stun-behavior for UDP and TCP an= d >> stun-behaviors for TLS/TCP. >> =C2=A0 =C2=A0 * Add SRV registry subsection to IANA section. > > Hi Bruce, > > It seems that you failed to address a number of issues from my AD > comments. Can you please motivate, or was this simply forgotten. > > cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Phon= e =C2=A0+46 10 7148287 > F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From marcelo@it.uc3m.es Tue Mar 10 03:59: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 6499328C0E2 for ; Tue, 10 Mar 2009 03:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, J_CHICKENPOX_75=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 xSBraN5sI12V for ; Tue, 10 Mar 2009 03:59:35 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0F2C13A6855 for ; Tue, 10 Mar 2009 03:59:35 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (131.pool85-53-143.dynamic.orange.es [85.53.143.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 357606B0A50; Tue, 10 Mar 2009 12:00:08 +0100 (CET) Message-ID: <49B64838.4020608@it.uc3m.es> Date: Tue, 10 Mar 2009 12:00:08 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: pierre.levis@orange-ftgroup.com References: <49B4E949.3040601@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-5.6.0.1016-16510.006 Cc: h.miyata@jp.yokogawa.com, behave@ietf.org Subject: Re: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-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: Tue, 10 Mar 2009 10:59:36 -0000 Hi Pierre, pierre.levis@orange-ftgroup.com escribió: > Dear authors, > > Thank you for this draft. > > Some quite generic comments: > > Do you think the scope of this document can be enlarged, keeping the focus on how to choose Prefix64? > that makes perfect sense to me I mean, if we decide to go for a WK prefix, then this can be used for any other usage that needs an IPv4 address representation in IPv6 address space. > I'm thinking of some IPv4 into IPv6 encapsulation scenarios (and not only translation scenarios). > In these scenarios you build the IPv6 destination address of the IPv6 packet that will encapsulate an IPv4 packet, based only on the information of the IPv4 packet (mainly A+P). The encapsulation is then stateless. > Typically, the IPv6 destination address has the generic format you provide in Fig 2.1. > Examples can be found in I-D.boucadair-behave-ipv6-portrange and in I-D.despres-sam-scenarios. > right, so what would be the differences between using a WK prefix and a LIR prefix in this case? > In some cases, the IPv4 address may be represented differently as simply the rough 32 bits. This is in order to force the total prefix length (PREFIX64+IPv4 address+extra info) to stay within a given boundary (e.g. /64). Space concern can be important when you need to put not only an IPv4 address but also a port information in the IPv6 address. Example of construction can be found in I-D.despres-sam. > > Do you think the potential issue is the number of bit that you need? I.e. having a shorter prefix could be more useful and this is harder to achieve with a LIR prefix? or are you thinking in something else? > In the first Figure in section "5.1. IPv6 Routing system scalability": > I don't see why, and how, the IPv4 site is connected to an IPv6 ISP, and precisely to the very one that connects the IPv6 site it communicates with? > right, i should have included a NAT64 box between the IPv4 site and the IPv6 ISP sorry for that the point here is that the IPv4 site has servers that want to be reachabel from the IPv6 internet, make sense now? Regards,marcelo > > Regards, > > Pierre > > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de marcelo bagnulo braun > Envoyé : lundi 9 mars 2009 11:03 > Ŕ : Behave WG > Objet : [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-02.txt] > > I have submitted a new version of this one, cause i missed one set of > comments is received in the previous one > > sorry for the confusion > > regards, marcelo > > > -------- Mensaje original -------- > Asunto: I-D Action:draft-miyata-behave-prefix64-02.txt > Fecha: Mon, 9 Mar 2009 02:45:02 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : PREFIX64 Comparison > Author(s) : H. Miyata, M. Bagnulo > Filename : draft-miyata-behave-prefix64-02.txt > Pages : 24 > Date : 2009-03-09 > > This draft compares different IPv6 prefix formats that can be used by > IPv6-IPv4 translator to represent IPv4 addresses in the IPv6 > Internet. The goal of the draft is asses the benefits and problems > of each proposed format and make a recommendation about which prefix > to use in the different scenarios considered. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-miyata-behave-prefix64-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. > > > > From magnus.westerlund@ericsson.com Tue Mar 10 05:38: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 7DA803A6B17 for ; Tue, 10 Mar 2009 05:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_SE=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 EK7q4UsAMjn4 for ; Tue, 10 Mar 2009 05:38:32 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C7AF93A6993 for ; Tue, 10 Mar 2009 05:38:31 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B6EE220542; Tue, 10 Mar 2009 13:39:05 +0100 (CET) X-AuditID: c1b4fb3c-af00dbb000001b43-cd-49b65f6916df Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 96CEC203E2; Tue, 10 Mar 2009 13:39:05 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 13:39:05 +0100 Received: from [147.214.183.107] ([147.214.183.107]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 13:39:05 +0100 Message-ID: <49B65F69.7000700@ericsson.com> Date: Tue, 10 Mar 2009 13:39:05 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Bruce Lowekamp References: <49B63719.6010208@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 10 Mar 2009 12:39:05.0227 (UTC) FILETIME=[32D05DB0:01C9A17D] X-Brightmail-Tracker: AAAAAA== Cc: behave Mailing List Subject: Re: [BEHAVE] draft-ietf-behave-nat-behavior-discovery-06 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: Tue, 10 Mar 2009 12:38:33 -0000 Hi Bruce, I am sorry, looking at the diff from 04 to 06 seems to indicate that yes the issues are resolved. I thought I checked in the 06 about STUN and thought you haven't changed the acronym which made me punt all over to you. I will start IETF last call. It will be a week extra due to IETF meeting. Cheers Magnus Bruce Lowekamp skrev: > Magnus, > > I believe that most of your comments were resolved in -05. The one > remaining issue (which was introduced in -05) was resolved by the > source port selection text being expanded and given its own subsection > in -06. At least, that's what I have in my notes and my understanding > from our email thread last November (unfortunate that it's been > delayed so long). Please let me know if you believe there are other > outstanding issues. > > Bruce > > Changelog from -05: > A.6. from draft-ietf-behave-nat-behavior-discovery-04 > > > o Clarified that behavior may vary by port used as well as by > destination IP/particular STUN server, and therefore specified > that all tests should be performed using the port the application > will use > > o Added additional text on selecting random port/ensuring port has > been unused prior to starting filtering tests > > o specified limit to start rate of tests and that tests > retransmissions should not synchronize > > o additional explanatory text for XOR-RESPONSE-TARGET > > o added SRV entry to IANA section and subdivided to match STUN > registries from 5389 > > o clarified that test combinations are non-normative > > o Numerous clarifications > > o Changed PADDING to default to interface MTU, and changed maximum > length to not make IP datagram exceed 64K > > o Added text that server should allocate TCP and TCP/TLS > > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From wwwrun@core3.amsl.com Tue Mar 10 07:44:14 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 B66263A6A6D; Tue, 10 Mar 2009 07:44:14 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090310144414.B66263A6A6D@core3.amsl.com> Date: Tue, 10 Mar 2009 07:44:14 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] Last Call: draft-ietf-behave-nat-behavior-discovery (NAT Behavior Discovery Using STUN) to Experimental RFC 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: Tue, 10 Mar 2009 14:44:14 -0000 The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'NAT Behavior Discovery Using STUN ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-31. 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-nat-behavior-discovery-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15728&rfc_flag=0 The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/919/ https://datatracker.ietf.org/ipr/945/ From jdrosen@cisco.com Tue Mar 10 13:12: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 6E9C13A6A55 for ; Tue, 10 Mar 2009 13:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 yYpBGCR3HQdV for ; Tue, 10 Mar 2009 13:12:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 67F033A6A34 for ; Tue, 10 Mar 2009 13:12:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,337,1233532800"; d="scan'208";a="153711745" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 10 Mar 2009 20:13:07 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2AKD8AS020197; Tue, 10 Mar 2009 13:13:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2AKD1OP025982; Tue, 10 Mar 2009 20:13:07 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 13:13:04 -0700 Received: from [10.32.241.157] ([10.32.241.157]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 13:13:03 -0700 Message-ID: <49B6C9CF.50907@cisco.com> Date: Tue, 10 Mar 2009 16:13:03 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Simon Perreault References: <20090304194502.13A203A6830@core3.amsl.com> <49B33F69.7070907@acm.org> <49B3D28D.4020700@viagenie.ca> <49B3F1D6.10400@acm.org> <49B42B9A.30703@viagenie.ca> In-Reply-To: <49B42B9A.30703@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2009 20:13:03.0707 (UTC) FILETIME=[9E3692B0:01C9A1BC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1825; t=1236715988; x=1237579988; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20I-D=20Action=3Adraft-ietf-be have-turn-tcp-02.txt |Sender:=20; bh=Mpyw11idioLRGev8o4DS1z55dpmpgOa1IBl/DGSUsds=; b=X0YFCrKvyAUAZBqXDOerbgizSECvkBsQL0rTgWIzJvog0+aeQwylsm1chv kiBrlc9ZP2gABBzOFnwsuW1LeCFRgsEG+fvT46R1+6/Cu0V2U+qHJ/a929lP 4prrfPXUfb; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Tue, 10 Mar 2009 20:12:33 -0000 I support that change. Couple of other comments: * ICE-tcp has the concept of active relayed candidates. For those, the client needs to have the TURN server initiate a TCP connection, but use a *different* port on the same IP address. There needs to be some way to do that here. I'm wondering if one idea is to allow clients to initiate a Connect request without having previously done an Allocate. * THe current text requires the TURN server to accept incoming connections and THEN inform the client of this. However, the client might refuse it, or timeout. I think it would be better to have the TURN server inform the client, and only once the client sends a ConnectionBind, THEN the TURN server accepts the connection. * As with UDP TURN, there needs to be keepalives on the allocation and on the data connection. The data connection, out of necessity, is refreshed by data, whereas the allocation is refreshed by a new Allocate Thanks, Jonathan R. Simon Perreault wrote: > Marc Petit-Huguenin wrote: >> It it possible to create multiple sockets with SO_REUSEADDR that are >> all bound to the same IP address and port. The TURN TCP protocol >> can hide this and simply allow multiple incoming or outgoing >> connections, simultaneously or sequentially. > > Indeed. Hmmm... This means we could do away with the Listen request > completely. Unless somebody objects, I'll remove the Listen request in > the next revision, as well as all restrictions related to the above. > > Simon -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From simon.perreault@viagenie.ca Tue Mar 10 13:42: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 EE2343A6B62 for ; Tue, 10 Mar 2009 13:42:17 -0700 (PDT) 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.157, 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 3U5Y+gZFUfEe for ; Tue, 10 Mar 2009 13:42:16 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 954ED3A6B31 for ; Tue, 10 Mar 2009 13:42:16 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 7B3BB29E1581; Tue, 10 Mar 2009 16:42:51 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 6BD6B29E1552; Tue, 10 Mar 2009 16:42:51 -0400 (EDT) Message-ID: <49B6D0CB.8050903@viagenie.ca> Date: Tue, 10 Mar 2009 16:42:51 -0400 From: Simon Perreault User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Jonathan Rosenberg References: <20090304194502.13A203A6830@core3.amsl.com> <49B33F69.7070907@acm.org> <49B3D28D.4020700@viagenie.ca> <49B3F1D6.10400@acm.org> <49B42B9A.30703@viagenie.ca> <49B6C9CF.50907@cisco.com> In-Reply-To: <49B6C9CF.50907@cisco.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Tue, 10 Mar 2009 20:42:18 -0000 Jonathan Rosenberg wrote: > * ICE-tcp has the concept of active relayed candidates. For those, the > client needs to have the TURN server initiate a TCP connection, but use > a *different* port on the same IP address. There needs to be some way to > do that here. I'm wondering if one idea is to allow clients to initiate > a Connect request without having previously done an Allocate. Can you explain the purpose of active relayed candidates? I searched in the archives but couldn't find anything. > * THe current text requires the TURN server to accept incoming > connections and THEN inform the client of this. However, the client > might refuse it, or timeout. I think it would be better to have the TURN > server inform the client, and only once the client sends a > ConnectionBind, THEN the TURN server accepts the connection. This would be ideal, however using the BSD sockets API there is no way to check permissions before accepting the connection, because we don't know the address of the peer yet. We could have the server only check permissions after the client has accepted the connection, but I think this would be even dirtier than what we have now. > * As with UDP TURN, there needs to be keepalives on the allocation and > on the data connection. The data connection, out of necessity, is > refreshed by data, whereas the allocation is refreshed by a new Allocate Absolutely. The question is how? Right now it is specified that the TURN server never interprets data on a data connection, it just forwards it as-is. So we cannot have a "no-op" at the TURN level, only at the application protocol level. We could use TCP keepalives but there are the usual implementation problems. Or we could break the "do not interpret data" rule, introduce a special "no-op", and introduce escaping rules for ordinary data that matches the "no-op" pattern. Then there's the lazy alternative where we specify that any application protocol related through TURN-TCP must do its own keepalive. Any ideas? Suggestions? Thanks, Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From kanda@ISI.EDU Tue Mar 10 14:17: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 33B493A695A for ; Tue, 10 Mar 2009 14:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kymedfKWp7Hr for ; Tue, 10 Mar 2009 14:17:13 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 315843A694F for ; Tue, 10 Mar 2009 14:17:13 -0700 (PDT) Received: from rickdias.karaba.org (kan.isi.edu [128.9.168.223]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n2ALHcK9011398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Mar 2009 14:17:40 -0700 (PDT) Date: Tue, 10 Mar 2009 14:20:25 -0700 Message-ID: <878wndulba.wl%mk@karaba.org> From: Mitsuru KANDA To: "behave@ietf.org" MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kanda@isi.edu Cc: bmanning@karoshi.com Subject: [BEHAVE] v4v6 Stateless Address Translator (IVI) and DNS Update (w/ DNSSEC) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 10 Mar 2009 21:17:14 -0000 Hello, Just announce, we implemented IVI (stateless address translator part) and DNS Update feature based on Dibbler DHCPv6 server. This feature updates both IPv6 (IVI6 - AAAA) and (mapped) IPv4 (IVI4 - A) address (and PTR RRs). And also we confirmed the DNSSEC incremental signing works fine in this dynamic DNS Update zone. Of course, this implementation is still experimental. But if you are interested in this, please visit ftp://ftp.isi.edu/pub/bill/ivi-2009/. The source code (patch file) , sample configs and document are available in this directory. For more information, please read ftp://ftp.isi.edu/pub/bill/ivi-2009/00README.DNS_Update. Regards, -mk From H.Miyata@jp.yokogawa.com Tue Mar 10 16:51: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 685303A6867 for ; Tue, 10 Mar 2009 16:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.504 X-Spam-Level: * X-Spam-Status: No, score=1.504 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_75=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k+Heio1JMOf for ; Tue, 10 Mar 2009 16:51:12 -0700 (PDT) Received: from zns001-0m9002.yokogawa.co.jp (zns001-0m9002.yokogawa.co.jp [203.174.79.139]) by core3.amsl.com (Postfix) with ESMTP id 358A13A67DD for ; Tue, 10 Mar 2009 16:51:11 -0700 (PDT) Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n2ANpjDF015569; Wed, 11 Mar 2009 08:51:45 +0900 (JST) Received: from zex001-0m9027.jp.ykgw.net (zex001-0m9027.jp.ykgw.net [10.0.11.46]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n2ANpYrl015533; Wed, 11 Mar 2009 08:51:41 +0900 (JST) Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9027.jp.ykgw.net ([10.0.11.46]) with mapi; Wed, 11 Mar 2009 08:51:36 +0900 From: To: , , Date: Wed, 11 Mar 2009 08:51:35 +0900 Thread-Topic: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-02.txt] Thread-Index: AcmgnjkSdga6PG/cRoqRWFOFtIzAMQAtml/QAAFbwYAAAMFZoAAfHspQ Message-ID: References: <49B4E949.3040601@it.uc3m.es> In-Reply-To: Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-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: Tue, 10 Mar 2009 23:51:13 -0000 Hi Pierre, Maybe it is true that those are not different. My point is it is better to discuss forcusing on each nature, purpose etc..= . purely. And, as the conclusion, if we concluded both has very similar nature, those= =20 could be conbined or refered each other. Making two things always delays the progress. Of course if you think both are almost same, then you can refer to ours. I think it is the simplest way and make things speedy. I am not negative combining them itself if it is reasonable. What I am concerning is "Speed". How do you think? ------------------------------------ Hiroshi Miyata, Ubiquitous Field Computing Research Center, Corporate R&D Headquaters, Yokogawa Electric Corp. =20 > -----Original Message----- > From: pierre.levis@orange-ftgroup.com=20 > [mailto:pierre.levis@orange-ftgroup.com]=20 > Sent: Tuesday, March 10, 2009 6:09 PM > To: Miyata, Hiroshi (H.Miyata@jp.yokogawa.com);=20 > marcelo@it.uc3m.es; behave@ietf.org > Subject: RE: [BEHAVE] [Fwd: I-D=20 > Action:draft-miyata-behave-prefix64-02.txt] >=20 >=20 > Well, as far as Prefix64 is concerned, I don't think the two=20 > contexts and analyses would be that different. > How you retrieve, know, which Prefix64 to select, seems quite=20 > independent on what the packet bears. > Once the IPv6 packet is formed, whether it carries an IPv4=20 > packet or a TCP segment (or whatsoever), the routing issues=20 > apply in the same way. >=20 > Pierre >=20 >=20 >=20 > -----Message d'origine----- > De : H.Miyata@jp.yokogawa.com=20 > [mailto:H.Miyata@jp.yokogawa.com] Envoy=E9 : mardi 10 mars 2009=20 > 09:32 =C0 : LEVIS Pierre RD-CORE-CAE; marcelo@it.uc3m.es;=20 > behave@ietf.org Objet : RE: [BEHAVE] [Fwd: I-D=20 > Action:draft-miyata-behave-prefix64-02.txt] >=20 > Hi Pierre, >=20 > Thanks for your comments and proposal. >=20 > This is very quick reply to your first proposal. >=20 > Unfortunately, I think the work should be proceeded separately. > Sinced the context is different, the analysis should be different. > It eventually accelerate the discussion. >=20 > Regards, >=20 > ------------------------------------ > Hiroshi Miyata, > Ubiquitous Field Computing Research Center, Corporate R&D=20 > Headquaters, Yokogawa Electric Corp. >=20 > =20 >=20 > > -----Original Message----- > > From: pierre.levis@orange-ftgroup.com=20 > > [mailto:pierre.levis@orange-ftgroup.com] > > Sent: Tuesday, March 10, 2009 5:21 PM > > To: marcelo@it.uc3m.es; behave@ietf.org; Miyata, Hiroshi > > (H.Miyata@jp.yokogawa.com) > > Subject: RE: [BEHAVE] [Fwd: I-D > > Action:draft-miyata-behave-prefix64-02.txt] > >=20 > > Dear authors, > >=20 > > Thank you for this draft. > >=20 > > Some quite generic comments: > >=20 > > Do you think the scope of this document can be enlarged,=20 > keeping the=20 > > focus on how to choose Prefix64? > > I'm thinking of some IPv4 into IPv6 encapsulation scenarios=20 > (and not=20 > > only translation scenarios). > > In these scenarios you build the IPv6 destination address=20 > of the IPv6=20 > > packet that will encapsulate an IPv4 packet, based only on the=20 > > information of the IPv4 packet (mainly A+P). The=20 > encapsulation is then=20 > > stateless. > > Typically, the IPv6 destination address has the generic format you=20 > > provide in Fig 2.1. > > Examples can be found in I-D.boucadair-behave-ipv6-portrange > > and in I-D.despres-sam-scenarios. > >=20 > > In some cases, the IPv4 address may be represented differently as=20 > > simply the rough 32 bits. This is in order to force the=20 > total prefix=20 > > length (PREFIX64+IPv4 address+extra > > info) to stay within a given boundary (e.g. /64). Space=20 > concern can be=20 > > important when you need to put not only an > > IPv4 address but also a port information in the IPv6 address.=20 > > Example of construction can be found in I-D.despres-sam. > >=20 > > In the first Figure in section "5.1. IPv6 Routing system > > scalability": > > I don't see why, and how, the IPv4 site is connected to an > > IPv6 ISP, and precisely to the very one that connects the > > IPv6 site it communicates with? > >=20 > >=20 > > Regards, > >=20 > > Pierre > > =20 > >=20 > > -----Message d'origine----- > > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org]=20 > > De la part de marcelo bagnulo braun Envoy=E9 : lundi 9 mars=20 > > 2009 11:03 =C0 : Behave WG Objet : [BEHAVE] [Fwd: I-D=20 > > Action:draft-miyata-behave-prefix64-02.txt] > >=20 > > I have submitted a new version of this one, cause i missed=20 > > one set of comments is received in the previous one > >=20 > > sorry for the confusion > >=20 > > regards, marcelo > >=20 > >=20 > > -------- Mensaje original -------- > > Asunto: I-D Action:draft-miyata-behave-prefix64-02.txt > > Fecha: Mon, 9 Mar 2009 02:45:02 -0700 (PDT) > > De: Internet-Drafts@ietf.org > > Responder a: internet-drafts@ietf.org > > Para: i-d-announce@ietf.org > >=20 > >=20 > >=20 > > A New Internet-Draft is available from the on-line=20 > > Internet-Drafts directories. > >=20 > > Title : PREFIX64 Comparison > > Author(s) : H. Miyata, M. Bagnulo > > Filename : draft-miyata-behave-prefix64-02.txt > > Pages : 24 > > Date : 2009-03-09 > >=20 > > This draft compares different IPv6 prefix formats that can=20 > be used by > > IPv6-IPv4 translator to represent IPv4 addresses in the IPv6=20 > > Internet. The goal of the draft is asses the benefits and=20 > > problems of each proposed format and make a recommendation=20 > > about which prefix to use in the different scenarios considered. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-miyata-behave-prefix > > 64-02.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=20 > > reader implementation to automatically retrieve the ASCII=20 > > version of the Internet-Draft. > >=20 > >=20 > >=20 > = From mohamed.boucadair@orange-ftgroup.com Tue Mar 10 22:51: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 F259D3A67CF for ; Tue, 10 Mar 2009 22:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_75=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 mQDs0n7lKk7B for ; Tue, 10 Mar 2009 22:51:15 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 583A23A6767 for ; Tue, 10 Mar 2009 22:51:14 -0700 (PDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 06:51: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, 11 Mar 2009 06:51:34 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007D88994@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-02.txt] Thread-Index: AcmgnjkSdga6PG/cRoqRWFOFtIzAMQAtml/QAAFbwYAAAMFZoAAfHspQAAy+EOA= References: <49B4E949.3040601@it.uc3m.es> From: To: , , , X-OriginalArrivalTime: 11 Mar 2009 05:51:38.0186 (UTC) FILETIME=[71A7B2A0:01C9A20D] Subject: Re: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-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, 11 Mar 2009 05:51:16 -0000 Hi all, I fully agree with Pierre that there is no difference between the both = (which should be teated simultaneousily). Cheers Med =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de H.Miyata@jp.yokogawa.com Envoy=E9 : mercredi 11 mars 2009 00:52 =C0 : LEVIS Pierre RD-CORE-CAE; marcelo@it.uc3m.es; behave@ietf.org Objet : Re: [BEHAVE] [Fwd: I-D = Action:draft-miyata-behave-prefix64-02.txt] Hi Pierre, Maybe it is true that those are not different. My point is it is better to discuss forcusing on each nature, purpose = etc... purely. And, as the conclusion, if we concluded both has very similar nature, = those could be conbined or refered each other. Making two things always delays the progress. Of course if you think both are almost same, then you can refer to ours. I think it is the simplest way and make things speedy. I am not negative combining them itself if it is reasonable. What I am concerning is "Speed". How do you think? ------------------------------------ Hiroshi Miyata, Ubiquitous Field Computing Research Center, Corporate R&D Headquaters, = Yokogawa Electric Corp. =20 > -----Original Message----- > From: pierre.levis@orange-ftgroup.com=20 > [mailto:pierre.levis@orange-ftgroup.com] > Sent: Tuesday, March 10, 2009 6:09 PM > To: Miyata, Hiroshi (H.Miyata@jp.yokogawa.com); marcelo@it.uc3m.es;=20 > behave@ietf.org > Subject: RE: [BEHAVE] [Fwd: I-D > Action:draft-miyata-behave-prefix64-02.txt] >=20 >=20 > Well, as far as Prefix64 is concerned, I don't think the two contexts=20 > and analyses would be that different. > How you retrieve, know, which Prefix64 to select, seems quite=20 > independent on what the packet bears. > Once the IPv6 packet is formed, whether it carries an IPv4 packet or a = > TCP segment (or whatsoever), the routing issues apply in the same way. >=20 > Pierre >=20 >=20 >=20 > -----Message d'origine----- > De : H.Miyata@jp.yokogawa.com > [mailto:H.Miyata@jp.yokogawa.com] Envoy=E9 : mardi 10 mars 2009 > 09:32 =C0 : LEVIS Pierre RD-CORE-CAE; marcelo@it.uc3m.es;=20 > behave@ietf.org Objet : RE: [BEHAVE] [Fwd: I-D=20 > Action:draft-miyata-behave-prefix64-02.txt] >=20 > Hi Pierre, >=20 > Thanks for your comments and proposal. >=20 > This is very quick reply to your first proposal. >=20 > Unfortunately, I think the work should be proceeded separately. > Sinced the context is different, the analysis should be different. > It eventually accelerate the discussion. >=20 > Regards, >=20 > ------------------------------------ > Hiroshi Miyata, > Ubiquitous Field Computing Research Center, Corporate R&D Headquaters, = > Yokogawa Electric Corp. >=20 > =20 >=20 > > -----Original Message----- > > From: pierre.levis@orange-ftgroup.com=20 > > [mailto:pierre.levis@orange-ftgroup.com] > > Sent: Tuesday, March 10, 2009 5:21 PM > > To: marcelo@it.uc3m.es; behave@ietf.org; Miyata, Hiroshi > > (H.Miyata@jp.yokogawa.com) > > Subject: RE: [BEHAVE] [Fwd: I-D > > Action:draft-miyata-behave-prefix64-02.txt] > >=20 > > Dear authors, > >=20 > > Thank you for this draft. > >=20 > > Some quite generic comments: > >=20 > > Do you think the scope of this document can be enlarged, > keeping the > > focus on how to choose Prefix64? > > I'm thinking of some IPv4 into IPv6 encapsulation scenarios > (and not > > only translation scenarios). > > In these scenarios you build the IPv6 destination address > of the IPv6 > > packet that will encapsulate an IPv4 packet, based only on the=20 > > information of the IPv4 packet (mainly A+P). The > encapsulation is then > > stateless. > > Typically, the IPv6 destination address has the generic format you=20 > > provide in Fig 2.1. > > Examples can be found in I-D.boucadair-behave-ipv6-portrange > > and in I-D.despres-sam-scenarios. > >=20 > > In some cases, the IPv4 address may be represented differently as=20 > > simply the rough 32 bits. This is in order to force the > total prefix > > length (PREFIX64+IPv4 address+extra > > info) to stay within a given boundary (e.g. /64). Space > concern can be > > important when you need to put not only an > > IPv4 address but also a port information in the IPv6 address.=20 > > Example of construction can be found in I-D.despres-sam. > >=20 > > In the first Figure in section "5.1. IPv6 Routing system > > scalability": > > I don't see why, and how, the IPv4 site is connected to an > > IPv6 ISP, and precisely to the very one that connects the > > IPv6 site it communicates with? > >=20 > >=20 > > Regards, > >=20 > > Pierre > > =20 > >=20 > > -----Message d'origine----- > > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la=20 > > part de marcelo bagnulo braun Envoy=E9 : lundi 9 mars > > 2009 11:03 =C0 : Behave WG Objet : [BEHAVE] [Fwd: I-D=20 > > Action:draft-miyata-behave-prefix64-02.txt] > >=20 > > I have submitted a new version of this one, cause i missed one set=20 > > of comments is received in the previous one > >=20 > > sorry for the confusion > >=20 > > regards, marcelo > >=20 > >=20 > > -------- Mensaje original -------- > > Asunto: I-D Action:draft-miyata-behave-prefix64-02.txt > > Fecha: Mon, 9 Mar 2009 02:45:02 -0700 (PDT) > > De: Internet-Drafts@ietf.org > > Responder a: internet-drafts@ietf.org > > Para: i-d-announce@ietf.org > >=20 > >=20 > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > > Title : PREFIX64 Comparison > > Author(s) : H. Miyata, M. Bagnulo > > Filename : draft-miyata-behave-prefix64-02.txt > > Pages : 24 > > Date : 2009-03-09 > >=20 > > This draft compares different IPv6 prefix formats that can > be used by > > IPv6-IPv4 translator to represent IPv4 addresses in the IPv6=20 > > Internet. The goal of the draft is asses the benefits and problems=20 > > of each proposed format and make a recommendation about which prefix = > > to use in the different scenarios considered. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-miyata-behave-prefix > > 64-02.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=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 > >=20 > >=20 >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From pierre.levis@orange-ftgroup.com Wed Mar 11 03:47: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 1D24E3A6B62 for ; Wed, 11 Mar 2009 03:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.829 X-Spam-Level: X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_75=0.6, 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 73lQpvwFFUUi for ; Wed, 11 Mar 2009 03:47:26 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 72A0E3A6B45 for ; Wed, 11 Mar 2009 03:47:26 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 11:47:47 +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, 11 Mar 2009 11:47:46 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-02.txt] Thread-Index: AcmgnjkSdga6PG/cRoqRWFOFtIzAMQAtml/QAAFbwYAAAMFZoAAfHspQABY+ZZA= References: <49B4E949.3040601@it.uc3m.es> From: To: , , X-OriginalArrivalTime: 11 Mar 2009 10:47:47.0742 (UTC) FILETIME=[D122C3E0:01C9A236] Subject: Re: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-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, 11 Mar 2009 10:47:28 -0000 I understand your point,=20 However, on the other hand, we could lose time if we only confront the = two tracks at the end. For me the important point is: if there are two tracks followed = separatly for Prefix64 issues: one for translation, one for = encapsulation, the two should evolve and exchange quite closely. Pierre -----Message d'origine----- De : H.Miyata@jp.yokogawa.com [mailto:H.Miyata@jp.yokogawa.com]=20 Envoy=E9 : mercredi 11 mars 2009 00:52 =C0 : LEVIS Pierre RD-CORE-CAE; marcelo@it.uc3m.es; behave@ietf.org Objet : RE: [BEHAVE] [Fwd: I-D = Action:draft-miyata-behave-prefix64-02.txt] Hi Pierre, Maybe it is true that those are not different. My point is it is better to discuss forcusing on each nature, purpose = etc... purely. And, as the conclusion, if we concluded both has very similar nature, = those=20 could be conbined or refered each other. Making two things always delays the progress. Of course if you think both are almost same, then you can refer to ours. I think it is the simplest way and make things speedy. I am not negative combining them itself if it is reasonable. What I am concerning is "Speed". How do you think? ------------------------------------ Hiroshi Miyata, Ubiquitous Field Computing Research Center, Corporate R&D Headquaters, Yokogawa Electric Corp. =20 > -----Original Message----- > From: pierre.levis@orange-ftgroup.com=20 > [mailto:pierre.levis@orange-ftgroup.com]=20 > Sent: Tuesday, March 10, 2009 6:09 PM > To: Miyata, Hiroshi (H.Miyata@jp.yokogawa.com);=20 > marcelo@it.uc3m.es; behave@ietf.org > Subject: RE: [BEHAVE] [Fwd: I-D=20 > Action:draft-miyata-behave-prefix64-02.txt] >=20 >=20 > Well, as far as Prefix64 is concerned, I don't think the two=20 > contexts and analyses would be that different. > How you retrieve, know, which Prefix64 to select, seems quite=20 > independent on what the packet bears. > Once the IPv6 packet is formed, whether it carries an IPv4=20 > packet or a TCP segment (or whatsoever), the routing issues=20 > apply in the same way. >=20 > Pierre >=20 >=20 >=20 > -----Message d'origine----- > De : H.Miyata@jp.yokogawa.com=20 > [mailto:H.Miyata@jp.yokogawa.com] Envoy=E9 : mardi 10 mars 2009=20 > 09:32 =C0 : LEVIS Pierre RD-CORE-CAE; marcelo@it.uc3m.es;=20 > behave@ietf.org Objet : RE: [BEHAVE] [Fwd: I-D=20 > Action:draft-miyata-behave-prefix64-02.txt] >=20 > Hi Pierre, >=20 > Thanks for your comments and proposal. >=20 > This is very quick reply to your first proposal. >=20 > Unfortunately, I think the work should be proceeded separately. > Sinced the context is different, the analysis should be different. > It eventually accelerate the discussion. >=20 > Regards, >=20 > ------------------------------------ > Hiroshi Miyata, > Ubiquitous Field Computing Research Center, Corporate R&D=20 > Headquaters, Yokogawa Electric Corp. >=20 > =20 >=20 > > -----Original Message----- > > From: pierre.levis@orange-ftgroup.com=20 > > [mailto:pierre.levis@orange-ftgroup.com] > > Sent: Tuesday, March 10, 2009 5:21 PM > > To: marcelo@it.uc3m.es; behave@ietf.org; Miyata, Hiroshi > > (H.Miyata@jp.yokogawa.com) > > Subject: RE: [BEHAVE] [Fwd: I-D > > Action:draft-miyata-behave-prefix64-02.txt] > >=20 > > Dear authors, > >=20 > > Thank you for this draft. > >=20 > > Some quite generic comments: > >=20 > > Do you think the scope of this document can be enlarged,=20 > keeping the=20 > > focus on how to choose Prefix64? > > I'm thinking of some IPv4 into IPv6 encapsulation scenarios=20 > (and not=20 > > only translation scenarios). > > In these scenarios you build the IPv6 destination address=20 > of the IPv6=20 > > packet that will encapsulate an IPv4 packet, based only on the=20 > > information of the IPv4 packet (mainly A+P). The=20 > encapsulation is then=20 > > stateless. > > Typically, the IPv6 destination address has the generic format you=20 > > provide in Fig 2.1. > > Examples can be found in I-D.boucadair-behave-ipv6-portrange > > and in I-D.despres-sam-scenarios. > >=20 > > In some cases, the IPv4 address may be represented differently as=20 > > simply the rough 32 bits. This is in order to force the=20 > total prefix=20 > > length (PREFIX64+IPv4 address+extra > > info) to stay within a given boundary (e.g. /64). Space=20 > concern can be=20 > > important when you need to put not only an > > IPv4 address but also a port information in the IPv6 address.=20 > > Example of construction can be found in I-D.despres-sam. > >=20 > > In the first Figure in section "5.1. IPv6 Routing system > > scalability": > > I don't see why, and how, the IPv4 site is connected to an > > IPv6 ISP, and precisely to the very one that connects the > > IPv6 site it communicates with? > >=20 > >=20 > > Regards, > >=20 > > Pierre > > =20 > >=20 > > -----Message d'origine----- > > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org]=20 > > De la part de marcelo bagnulo braun Envoy=E9 : lundi 9 mars=20 > > 2009 11:03 =C0 : Behave WG Objet : [BEHAVE] [Fwd: I-D=20 > > Action:draft-miyata-behave-prefix64-02.txt] > >=20 > > I have submitted a new version of this one, cause i missed=20 > > one set of comments is received in the previous one > >=20 > > sorry for the confusion > >=20 > > regards, marcelo > >=20 > >=20 > > -------- Mensaje original -------- > > Asunto: I-D Action:draft-miyata-behave-prefix64-02.txt > > Fecha: Mon, 9 Mar 2009 02:45:02 -0700 (PDT) > > De: Internet-Drafts@ietf.org > > Responder a: internet-drafts@ietf.org > > Para: i-d-announce@ietf.org > >=20 > >=20 > >=20 > > A New Internet-Draft is available from the on-line=20 > > Internet-Drafts directories. > >=20 > > Title : PREFIX64 Comparison > > Author(s) : H. Miyata, M. Bagnulo > > Filename : draft-miyata-behave-prefix64-02.txt > > Pages : 24 > > Date : 2009-03-09 > >=20 > > This draft compares different IPv6 prefix formats that can=20 > be used by > > IPv6-IPv4 translator to represent IPv4 addresses in the IPv6=20 > > Internet. The goal of the draft is asses the benefits and=20 > > problems of each proposed format and make a recommendation=20 > > about which prefix to use in the different scenarios considered. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-miyata-behave-prefix > > 64-02.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=20 > > reader implementation to automatically retrieve the ASCII=20 > > version of the Internet-Draft. > >=20 > >=20 > >=20 >=20 From petithug@acm.org Thu Mar 12 10:44: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 750C03A67EC for ; Thu, 12 Mar 2009 10:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.219 X-Spam-Level: X-Spam-Status: No, score=-102.219 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj5YIxA-k-ic for ; Thu, 12 Mar 2009 10:44:32 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 98C0F3A67E1 for ; Thu, 12 Mar 2009 10:44:32 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id DEB406C98498; Thu, 12 Mar 2009 17:45:09 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 966B46C98498 for ; Thu, 12 Mar 2009 17:45:05 +0000 (UTC) Message-ID: <49B94A20.8070208@acm.org> Date: Thu, 12 Mar 2009 10:45:04 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: behave@ietf.org References: <20090307233001.655363A6AA8@core3.amsl.com> <49B30626.1070801@acm.org> In-Reply-To: <49B30626.1070801@acm.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-uri-01.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, 12 Mar 2009 17:44:33 -0000 I formatted this draft so it can be installed on an Amazon Kindle: http://ietf.implementers.org/draft-ietf-behave-turn-uri-01.mobi Something to read on the plane to SFO or on the BART/Caltrain before the meeting and with a Kindle 2 you can even use text-to-speech. The Kindle is great also to annotate a document. Enjoy! Marc Petit-Huguenin wrote: > This new version just fixes one small imprecision discovered when > working on a new reference implementation. The draft could use more > feedback and if someone wants to implement TURN URI, I will be more > than happy to provide my reference implementation and a set of NAPTR > and SRV RR that I am developing to help the testing. > > Also draft-wood-tae-specifying-uri-transports proposes a different > way to specify the transport parameter in an URI. I would be happy > to discuss if and how this can be applied to a TURN URI. > > > Changelog: > > o Fixed the contact email. > o Changed the IPR to trust200902. > o Added case for transport defined but unknown. > o Moved RFC 3958 to Normative References. > o Added study of [I-D.wood-tae-specifying-uri-transports] in > TODO list. > > > 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 : Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers >> Author(s) : M. Petit-Huguenin >> Filename : draft-ietf-behave-turn-uri-01.txt >> Pages : 12 >> Date : 2009-03-07 >> >> This document defines two URI schemes and the resolution mechanism to >> convert these URIs to a list of server transport addresses that can >> be used between a Traversal Using Relays around NAT (TURN) client and >> server. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-uri-01.txt >> > -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From petithug@acm.org Thu Mar 12 10:49: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 C146828C248 for ; Thu, 12 Mar 2009 10:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.221 X-Spam-Level: X-Spam-Status: No, score=-102.221 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkhvIs4AI-Ed for ; Thu, 12 Mar 2009 10:49:40 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id A397C3A6916 for ; Thu, 12 Mar 2009 10:49:40 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 35EB16C9849A; Thu, 12 Mar 2009 17:50:18 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 7955A6C9849C for ; Thu, 12 Mar 2009 17:50:14 +0000 (UTC) Message-ID: <49B94B54.6050904@acm.org> Date: Thu, 12 Mar 2009 10:50:12 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: behave@ietf.org References: <20090304194502.13A203A6830@core3.amsl.com><49AEDCA0.2070602@viagenie.ca> <49AEE6C4.6080909@acm.org> <0adc01c99d14$41bfded0$c2f0200a@cisco.com> <49B566DD.3010609@acm.org> In-Reply-To: <49B566DD.3010609@acm.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] draft-petithuguenin-turn-tcp-variant-00.txt [was RE: I-D Action:draft-ietf-behave-turn-tcp-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: Thu, 12 Mar 2009 17:49:42 -0000 Marc Petit-Huguenin wrote: > Dan Wing wrote: >>> One missing open issue is multiple connections vs shared connection >>> (ala SSH). As far as I can read in the minutes of the Minneapolis >>> meeting and the subsequent discussions in the mailing-list, nothing >>> was decided. >> For everyone else's reference, here are pointers to the mailing list >> discussion of your proposal, >> draft-petithuguenin-turn-tcp-variant-00.txt: >> >> your announcement of the I-D: >> http://www.ietf.org/mail-archive/web/behave/current/msg04938.html >> >> Rémi Denis-Courmont's comments: >> http://www.ietf.org/mail-archive/web/behave/current/msg04942.html >> >> Simon Perreault's comments: >> http://www.ietf.org/mail-archive/web/behave/current/msg04939.html >> >> your followup: >> http://www.ietf.org/mail-archive/web/behave/current/msg04952.html >> where you wrote: >> >> > >> > Some of your arguments are absolutely true (HOLB), some are >> > debatable, and the others I have to think about them. >> > >> > But there is also some advantages to the single connection >> > solution, for example establishing a new peer TCP connection is >> > faster. Please also have a look to section 3.3.2 in the excellent >> > draft-iab-ip-model-evolution. >> > >> >> Please followup to Remi's comments in this thread. >> > > I submitted a new version of the turn-tcp-variant draft: > > http://www.ietf.org/internet-drafts/draft-petithuguenin-turn-tcp-variant-01.txt > > I put Remi's arguments inside the document as reasons not to adopt > this variant in TURN TCP. I also added arguments in favors of > adopting it :-) > > Comments are welcome. > The Kindle version: http://ietf.implementers.org/draft-petithuguenin-turn-tcp-variant-01.mobi -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From H.Miyata@jp.yokogawa.com Thu Mar 12 18:38: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 E288F3A67F6 for ; Thu, 12 Mar 2009 18:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_75=0.6, RDNS_DYNAMIC=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 BnKmbXaDZWva for ; Thu, 12 Mar 2009 18:38:22 -0700 (PDT) Received: from ns.64translator.com (70.145.221.202.bf.2iij.net [202.221.145.70]) by core3.amsl.com (Postfix) with ESMTP id 8DB543A67F2 for ; Thu, 12 Mar 2009 18:38:21 -0700 (PDT) Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.14.2/8.14.2) with ESMTP id n2D1bfMG062170; Fri, 13 Mar 2009 10:37:41 +0900 (JST) (envelope-from H.Miyata@jp.yokogawa.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by bahamas.64translator.com (8.13.6/8.13.6) with ESMTP id n2D1bVN9019417; Fri, 13 Mar 2009 10:37:32 +0900 (JST) (envelope-from H.Miyata@jp.yokogawa.com) Message-Id: From: MIYATA HIROSHI To: "" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Mar 2009 10:37:30 +0900 References: <49B4E949.3040601@it.uc3m.es> X-Mailer: Apple Mail (2.930.3) Cc: behave@ietf.org Subject: Re: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-prefix64-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: Fri, 13 Mar 2009 01:38:24 -0000 Pierre, I got your point. It is natural that if the purpose and/or nature are not same, the discussion should be separated. But if those are the same they must be discussed together. Anyway, let's meet and talk at SFO. ;-) ...miyata On 2009/03/11, at 19:47, = wrote: > > I understand your point, > However, on the other hand, we could lose time if we only confront =20 > the two tracks at the end. > For me the important point is: if there are two tracks followed =20 > separatly for Prefix64 issues: one for translation, one for =20 > encapsulation, the two should evolve and exchange quite closely. > > > Pierre > > -----Message d'origine----- > De : H.Miyata@jp.yokogawa.com [mailto:H.Miyata@jp.yokogawa.com] > Envoy=E9 : mercredi 11 mars 2009 00:52 > =C0 : LEVIS Pierre RD-CORE-CAE; marcelo@it.uc3m.es; behave@ietf.org > Objet : RE: [BEHAVE] [Fwd: I-D Action:draft-miyata-behave-=20 > prefix64-02.txt] > > Hi Pierre, > > Maybe it is true that those are not different. > My point is it is better to discuss forcusing on each nature, =20 > purpose etc... purely. > And, as the conclusion, if we concluded both has very similar =20 > nature, those > could be conbined or refered each other. > Making two things always delays the progress. > Of course if you think both are almost same, then you can refer to =20 > ours. > > I think it is the simplest way and make things speedy. > I am not negative combining them itself if it is reasonable. > What I am concerning is "Speed". > > How do you think? > > ------------------------------------ > Hiroshi Miyata, > Ubiquitous Field Computing Research Center, > Corporate R&D Headquaters, > Yokogawa Electric Corp. > > > >> -----Original Message----- >> From: pierre.levis@orange-ftgroup.com >> [mailto:pierre.levis@orange-ftgroup.com] >> Sent: Tuesday, March 10, 2009 6:09 PM >> To: Miyata, Hiroshi (H.Miyata@jp.yokogawa.com); >> marcelo@it.uc3m.es; behave@ietf.org >> Subject: RE: [BEHAVE] [Fwd: I-D >> Action:draft-miyata-behave-prefix64-02.txt] >> >> >> Well, as far as Prefix64 is concerned, I don't think the two >> contexts and analyses would be that different. >> How you retrieve, know, which Prefix64 to select, seems quite >> independent on what the packet bears. >> Once the IPv6 packet is formed, whether it carries an IPv4 >> packet or a TCP segment (or whatsoever), the routing issues >> apply in the same way. >> >> Pierre >> >> >> >> -----Message d'origine----- >> De : H.Miyata@jp.yokogawa.com >> [mailto:H.Miyata@jp.yokogawa.com] Envoy=E9 : mardi 10 mars 2009 >> 09:32 =C0 : LEVIS Pierre RD-CORE-CAE; marcelo@it.uc3m.es; >> behave@ietf.org Objet : RE: [BEHAVE] [Fwd: I-D >> Action:draft-miyata-behave-prefix64-02.txt] >> >> Hi Pierre, >> >> Thanks for your comments and proposal. >> >> This is very quick reply to your first proposal. >> >> Unfortunately, I think the work should be proceeded separately. >> Sinced the context is different, the analysis should be different. >> It eventually accelerate the discussion. >> >> Regards, >> >> ------------------------------------ >> Hiroshi Miyata, >> Ubiquitous Field Computing Research Center, Corporate R&D >> Headquaters, Yokogawa Electric Corp. >> >> >> >>> -----Original Message----- >>> From: pierre.levis@orange-ftgroup.com >>> [mailto:pierre.levis@orange-ftgroup.com] >>> Sent: Tuesday, March 10, 2009 5:21 PM >>> To: marcelo@it.uc3m.es; behave@ietf.org; Miyata, Hiroshi >>> (H.Miyata@jp.yokogawa.com) >>> Subject: RE: [BEHAVE] [Fwd: I-D >>> Action:draft-miyata-behave-prefix64-02.txt] >>> >>> Dear authors, >>> >>> Thank you for this draft. >>> >>> Some quite generic comments: >>> >>> Do you think the scope of this document can be enlarged, >> keeping the >>> focus on how to choose Prefix64? >>> I'm thinking of some IPv4 into IPv6 encapsulation scenarios >> (and not >>> only translation scenarios). >>> In these scenarios you build the IPv6 destination address >> of the IPv6 >>> packet that will encapsulate an IPv4 packet, based only on the >>> information of the IPv4 packet (mainly A+P). The >> encapsulation is then >>> stateless. >>> Typically, the IPv6 destination address has the generic format you >>> provide in Fig 2.1. >>> Examples can be found in I-D.boucadair-behave-ipv6-portrange >>> and in I-D.despres-sam-scenarios. >>> >>> In some cases, the IPv4 address may be represented differently as >>> simply the rough 32 bits. This is in order to force the >> total prefix >>> length (PREFIX64+IPv4 address+extra >>> info) to stay within a given boundary (e.g. /64). Space >> concern can be >>> important when you need to put not only an >>> IPv4 address but also a port information in the IPv6 address. >>> Example of construction can be found in I-D.despres-sam. >>> >>> In the first Figure in section "5.1. IPv6 Routing system >>> scalability": >>> I don't see why, and how, the IPv4 site is connected to an >>> IPv6 ISP, and precisely to the very one that connects the >>> IPv6 site it communicates with? >>> >>> >>> Regards, >>> >>> Pierre >>> >>> >>> -----Message d'origine----- >>> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] >>> De la part de marcelo bagnulo braun Envoy=E9 : lundi 9 mars >>> 2009 11:03 =C0 : Behave WG Objet : [BEHAVE] [Fwd: I-D >>> Action:draft-miyata-behave-prefix64-02.txt] >>> >>> I have submitted a new version of this one, cause i missed >>> one set of comments is received in the previous one >>> >>> sorry for the confusion >>> >>> regards, marcelo >>> >>> >>> -------- Mensaje original -------- >>> Asunto: I-D Action:draft-miyata-behave-prefix64-02.txt >>> Fecha: Mon, 9 Mar 2009 02:45:02 -0700 (PDT) >>> De: Internet-Drafts@ietf.org >>> Responder a: internet-drafts@ietf.org >>> Para: i-d-announce@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. >>> >>> Title : PREFIX64 Comparison >>> Author(s) : H. Miyata, M. Bagnulo >>> Filename : draft-miyata-behave-prefix64-02.txt >>> Pages : 24 >>> Date : 2009-03-09 >>> >>> This draft compares different IPv6 prefix formats that can >> be used by >>> IPv6-IPv4 translator to represent IPv4 addresses in the IPv6 >>> Internet. The goal of the draft is asses the benefits and >>> problems of each proposed format and make a recommendation >>> about which prefix to use in the different scenarios considered. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-miyata-behave-prefix >>> 64-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. >>> >>> >>> >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From remi.despres@free.fr Fri Mar 13 02:58: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 C2A913A6A0B; Fri, 13 Mar 2009 02:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.967 X-Spam-Level: X-Spam-Status: No, score=0.967 tagged_above=-999 required=5 tests=[AWL=-1.871, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, FRT_LITTLE=1.555, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZQkAUoWq-sM; Fri, 13 Mar 2009 02:58:32 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 43A1A3A67AF; Fri, 13 Mar 2009 02:58:18 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id B3F61E081A9; Fri, 13 Mar 2009 10:58:52 +0100 (CET) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id E3C27E08153; Fri, 13 Mar 2009 10:58:48 +0100 (CET) Message-ID: <49BA2DD6.8080001@free.fr> Date: Fri, 13 Mar 2009 10:56:38 +0100 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Internet Area , Softwires WG , Behave WG Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: [BEHAVE] FYI: draft-despres-sam-02 enclosed X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2009 09:58:45 -0000 Hi,
For your information, draft-despres-sam-02, which was ready too late to be posted before IETF 74, is enclosed below

It is a major update of the version-01 which was presented at IETF 73:
- In Softwires, ref.:
http://www.ietf.org/proceedings/08nov/slides/softwire-3/softwire-3_files/slide0002.htm 
- In Behave, ref.:
http://www.ietf.org/proceedings/08nov/slides/behave-15.pdf

In San Francisco, its part that deals with NAT66 avoidance is to be discussed at the 6IA BOF meeting (ex NAT66).
Its part that deals with Port-Range extension, is to be discussed at the SHARA BOF.

Comments most welcome. 

Regards,

RD






Internet Engineering Task Force                               R. Despres
Internet-Draft                                             November 2008
Intended status: Standards Track
Expires: May 5, 2009


                    Stateless Address Mapping (SAM)
      Avoiding NATs and restoring the end-to-end principle in IPv6
                          draft-despres-sam-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 May 5, 2009.

Abstract

   Stateless Address Mapping (SAM) is a generic mechanism to support
   global addressing across network zones where routing is based on a
   different address space.  With it, the end-to-end principle, lost in
   IPv4 with the deployment of NATs, can be restored without losing
   services that NAT44s offer beyond address-space extension (private
   addressing, basic firewall, site multihoming, privacy protection,
   host-rooted subnets).  Global-address packets are encapsulated in
   local-address packets to traverse SAM zones, and global prefixes are
   statelessly mapped into local addresses.  For the IPv6-IPv4
   coexistence period, port-restricted IPv4 addresses are used to extend
   the global IPv4 address space.



Despres                    Expires May 5, 2009                  [Page 1]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


Table of Contents

   1.  Introduction and general problem statement . . . . . . . . . .  3
   2.  NAT44 services availability of which in IPv6 is desirable  . .  4
     2.1.  Private addressing (easy renumbering)  . . . . . . . . . .  4
     2.2.  Basic firewall (by default, no incoming connections) . . .  4
     2.3.  Site multihoming (automatic fallback)  . . . . . . . . . .  4
     2.4.  Privacy protection . . . . . . . . . . . . . . . . . . . .  4
     2.5.  Host-rooted subnets  . . . . . . . . . . . . . . . . . . .  5
   3.  SAM specification  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Local Zones - Root SAMs - Branch SAMs  . . . . . . . . . .  5
     3.2.  Encapsulation of global packets in local packets . . . . .  7
     3.3.  Global prefixes - global addresses - local addresses . . .  9
     3.4.  Endpoint global address to branch local address mapping  . 11
     3.5.  Privacy protection . . . . . . . . . . . . . . . . . . . . 13
     3.6.  SAM parameters . . . . . . . . . . . . . . . . . . . . . . 15
     3.7.  Port-range-based extended IPv4 addressing  . . . . . . . . 16
   4.  SAM Application examples . . . . . . . . . . . . . . . . . . . 17
     4.1.  Address independence in an IPv6 site . . . . . . . . . . . 17
     4.2.  Multihoming and extended IPv4 addressing in a home site  . 19
   5.  SAM as an alternative to NATs in IPv6  . . . . . . . . . . . . 21
   6.  Security considerations  . . . . . . . . . . . . . . . . . . . 22
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 23
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 26






















Despres                    Expires May 5, 2009                  [Page 2]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


1.  Introduction and general problem statement

   In IPv4, Network Address Translations have been extensively deployed
   (NAT44s).  They are key to mitigate the IPv4 address shortage.  But
   they also offer various auxiliary services, described in Section 2:
   private addressing, basic firewall, site multihoming, privacy
   protection, host-rooted subnets.

   In counterpart to these auxiliary services, these NAT44s have
   introduced two drawbacks:

   o  Non compliance with the end-to-end principle of the Internet
      (e2e).

         Negative consequences include incompatibility with the IPsec
         security mechanism, and difficulties for hosts to know their
         own global addresses, which they need for connection
         redirections, for host referrals, and and, in sites having
         several site entrance routers, for multihoming support
         mechanisms like the SCTP of [RFC4960] and [Shim6].

   o  Stateful operation.

         Most NAT44s are in fact stateful NAPTs (ref. < xref
         target="RFC2663" />): to support more local addresses than they
         have external addresses, they maintain per-transport-connection
         states.  Negative consequences include limited scalability, and
         the risk of denial of service attacks that go with it, as well
         as single points of failures.

   Since no global address shortage is in view in IPv6, the following
   questions have to be asked:

   o  Which NAT44 services can, in IPv6, be offered statelessly and
      without breaking the e2e principle?

   o  How?

   This draft proposes to answer these questions more completely, and
   with more technical details, than [RFC4864], the most advance
   document on the subject so far.

   For this, a Stateless Address Mapping generic mechanism is introduced
   (SAM).

   Conclusion, is that, provided SAM is supported in nodes at borders of
   independently administered routing zones, the e2e principle can be
   restored in IPv6, for all identified useful functions of NAT44s.



Despres                    Expires May 5, 2009                  [Page 3]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


   (This conclusion needs however to be confirmed after further work on
   SAM details, after criticisms by other experts, after some possible
   bug corrections, and after validations with running code.)

   Thus, traversal of NATs in ISP infrastructures can be avoided.
   (These NATs do provide useful connectivity to some non-SAM-capable
   nodes, but have the drawback of breaking the e2e principle, with the
   mentioned consequences on security, referrals, multihoming,
   scalability and reliability.


2.  NAT44 services availability of which in IPv6 is desirable

2.1.  Private addressing (easy renumbering)

   With NAT44s, when a prefix assigned by an ISPs to a customer site is
   modified, local IP addresses in the site can remain unchanged.

2.2.  Basic firewall (by default, no incoming connections)

   Most NAT44s, being NAPTs, and therefore maintaining states for all
   TCP and UDP connections, have as a byproduct a protection against
   incoming connections (unless some "holes" are "punched" in this
   protection, under explicit customer control).  This level of security
   protection is largely relied upon.

2.3.  Site multihoming (automatic fallback)

   In a site is multi-homed, and if it has a NAT device supporting all
   its ISP interfaces, its hosts can take advantage of multihoming
   without having to support any multihoming-specific function.  This
   level of multihoming support is better than none.

   (For this, a NAT44 needs only to make sure that, for each transport
   connection, all outgoing packets go through the same ISP.  Thus, if
   an ISP access fails, current TCP and UDP connections that go via this
   ISP are broken, but theycan immediately be replaced by new ones.)

2.4.  Privacy protection

   From outside a site where a NAT44 operates in NAPT mode, it is
   difficult to determine which hosts establish which connections.  This
   level of privacy protection, in particular for some web requests, is
   an added value.







Despres                    Expires May 5, 2009                  [Page 4]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


2.5.  Host-rooted subnets

   Behind a host that is assigned a single IPv4 address, it is possible,
   with a NAT44 in the host, to deploy a private subnet.  As modern
   operating systems include a router function with a NAT44, a computer
   can can serve as a root for a LAN.

   Thus, the distinction between hosts and a routers is no longer a
   distinction between types of devices.  It has become only a
   distinction between functions within nodes.


3.  SAM specification

3.1.  Local Zones - Root SAMs - Branch SAMs

   As presented in Figure 1, the SAM mechanism applies to a SAM "local
   zone" Z. Routing within this zone is independently administered, and
   is based on a "local address space".

   Each SAM zone has one or several "root interfaces" (Ri), that give
   access to the global Internet.  Each one has, in the global Internet,
   one or several "global prefixes" (gZij) exclusively assigned to zone
   Z.

   SAM global prefixes can be global IPv6 and/or global IPv4.  SAM local
   address spaces can be IPv6 or IPv4, global or private.  If both IPv4
   and IPv6 are routed in the zone, one of the two is chosen for SAM.
   (SAM is in this respect therefore an extension of the 6to4 of
   [RFC3056], of the ISATAP of [RFC5214], and of [6rd], where all global
   prefixes are IPv6 and all local address spaces are IPv4).

   As explained in Section 3.7, global IPv4 addresses can be extended
   beyond 32 bits to deal with the IPv4 address shortage during the
   IPv4-IPv6 coexistence period.
















Despres                    Expires May 5, 2009                  [Page 5]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


                                         ROOT-SIDE ENDPOINTS
                                      |         /\            |
                                      |         ||            |
                                |_____:_____|   ||     |______:_____|
                                      |                       |
                                      |      ROOT ZONES       |
                                      |                      gZ22
    Zone Global prefixes gZij       gZ11                     gZ21
    Root interfaces:         _________:_______________________:________
                            |(Z)   (root-SAM)              (root-SAM)  |
    Root local addresses:   |         R1                       R2      |
            Ri              |                                          |
                            |                SAM ZONE Z                |
                            |                                          |
                            |                                          |
    Branch local addresses: |      B1               B2           B3   |
            Bk              |      :                :             :    |
    Branch interfaces:      |______:________________:_____________:____|
                                   |                |             |
    Branch Global prefixes:        |          (branch-SAM)        |
      *gBkij=gZij.zBk*               => + gB211, gB221, gB222
    Branch Global Addresses:            +  gB211@, gB221@, gB222@
      *gBkij@=gBkij.H*                              ||
                               BRANCH ZONES         ||
                                                    \/
                                          BRANCH-SIDE ENDPOINTS

                      ROOT AND BRANCH INTERFACES AND SAMs

                                 Figure 1

   Each root interface that supports a root-SAM function has a local
   address (Rk), and each "branch interface" has a local address (Bk).

   If a "branch SAM" function is supported at a branch interface Bk,
   this interface gets, in addition to its local address, global
   prefixes (gBkij).  Each of these prefixes is made of a global prefix
   of the zone (gZij) followed by an identifier (zBk) of the branch in
   its zone.

   For each each of its global prefixes gBkij, a branch interface has
   also a host global address (gBkij@), derived from the prefix by
   appending a standard host suffix (H) to complete the address length.

   Thus, if a zone D is accessible from the global Internet via a zone
   hierarchy A, B, C, it has at least gA.aB.bC.cD as a global prefix gD,
   and gA.aB.bC.cD.H as a global address gD@.  SAM is thus an
   application of the locator-identifier separation principle.  (It



Despres                    Expires May 5, 2009                  [Page 6]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


   differs however from [LISP], in that no new protocol is needed fro
   SAM, just new options in existing protocols such as DHCP [RFC2131],
   DHCPv6 [RFC3315], or ND [RFC4861], to advertise SAM parameters to
   branch interfaces.)

3.2.  Encapsulation of global packets in local packets


   endpoint Y Global address:                 gY
                                               ^
                                               |
                                              ...
   (3)  e2e packet:                    [ gX->gY [data]]
                                               ^
                                               |
                                              gZ         ROOT ZONE R
                                 ______________:______________________
                                |(Z)       (root SAM)                 |
                                |              R         LOCAL ZONE Z |
                                |              ^                      |
                                |              |                      |
                                |             ...                     |
   (2)  encapsulated packet:    |                                     |
         *B = la(gX)*           |      [  B->R [gX->gY[data]]         |
         *R = parameter*        |              ^                      |
                                |              |                      |
                                |              B                      |
                                |______________:______________________|
                                          (branch SAM)   BRANCH ZONE B
                                           => + gB
                                               ^
                                               |
                                              ...
   (1)  e2e packet:                    [ gX->gY [data]]
                                               ^
                                               |
   endpoint X Global address:          gX=gZ.id(B).xxx


     PACKET ENCAPSULATION AND ADDRESS MAPPING - BRANCH SIDE TO ROOT SIDE

                                 Figure 2

   To traverse a SAM local zone, global-address packets are encapsulated
   into local address packets, as illustrated in Figure 2 and Figure 3).

   Thus, compatibility is ensured, within the local zone, with ingress
   the filtering for multihomed networks of [RFC3704], the basic anti-



Despres                    Expires May 5, 2009                  [Page 7]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


   spoofing mechanism.


                                               |
                                               |           ROOT ZONE
                                              gZ
                                 ______________:______________________
                                |(Z)       (root-SAM)                 |
                                |              R         LOCAL ZONE Z |
                                |                                     |
                                |                                     |
                                |                                     |
   (2)  encapsulated packet:    |     [ B1->B2 [gE1->gE2[data]]       |
        *B1 = la(gX)*           |         -------->--------           |
        *B2 = la(gY)*           |       /                   \         |
                                |      ^                     |        |
                                |      |                     v        |
                                |      B1                    B2       |
                                |______:_____________________:________|
           BRANCH ZONES:          (branch-SAM)          (branch-SAM)
                                    => + gB1              => + gB2
                                       ^                     |
                                       |                     v
   (3)  e2e packet:                   ...              [ E1->E2 [data]]
   (1)  e2e packet:             [ E1->E2 [data]]             ...
                                       ^                     |
                                       |                     v
                               gX=gZ.id(B1).xxx         gY=gZ.id(B2).yyy
                                      _:_                   _:_
                                     | X |                 | Y |
                                     |___|                 |___|

   ADDRESS MAPPING AND PACKET ENCAPSULATION - BRANCH SIDE TO BRANCH SIDE

                                 Figure 3

   For the IP-in-IP encapsulation, the IPv6 next header or the IPv4
   protocol id which indicates the type of IP payload is set to 41 (the
   same value as for 6to4, ISATAP, and 6rd).

   Local addresses are determined as follows (illustrated in figures
   Figure 2 and Figure 3):

   1.  If an endpoint global address gE, indifferently source or
       destination, is that of a branch-side endpoint, this is
       recognized by the fact that it starts with one of the global
       prefixes of the zone.  Then, the local address B is obtained by a
       function B=la(gX), completely determined by SAM parameters of the



Despres                    Expires May 5, 2009                  [Page 8]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


       zone (details in Section 3.4).

   2.  If an endpoint global address gE, indifferently source or
       destination, is that of a root-side endpoint, this is recognized
       by the fact that it doesn't start with any of the global prefixes
       of the zone.  In this case, the other address gX of the packet,
       destination or source respectively, is necessarily that of a
       branch-side endpoint (otherwise the packet would not traverse the
       local zone).  Then, local address Ri is that of the root
       interface that has, in its assigned global prefixes, the global
       prefix present at the beginning of the branch-side address gX.

   In multihomed sites, the second of these rules ensures compatibility
   with the ingress filtering of [RFC3704] in root zones (if it does
   apply, as necessary for anti-spoofing protection).

   In Figure 2 and Figure 3, packets in the reverse direction, not
   shown, would have the same addresses but with sources and
   destinations inverted, and with encapsulations and decapsulations
   made at inverted interfaces.

   Decapsulation functions MUST verify, for anti-spoofing protection,
   that local addresses present in headers of encapsulating packets are
   consistent with global addresses present in headers of encapsulated
   packets.

3.3.  Global prefixes - global addresses - local addresses

   Internal structures of SAM global prefixes, global addresses, and
   local addresses are detailed in Figure 4.

   A branch-interface global prefix necessarily starts with a global
   prefix of the zone Z. Its remaining bits are a "branch identifier" in
   the zone (gBkij = gZij.zB).

















Despres                    Expires May 5, 2009                  [Page 9]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


             |<-------------- Branch global address gB@ ------------->|
             |<-------- Branch global prefix gB -------->             |
             |<-- G --><-----  Branch identifier iB ---->             |
              ________________________________________________________
             |  local  |branch|  Subnet |     branch     |   branch   |
             |  zone   |  id  |  index  |      Index     |    Host    |
             |  Global |Format| (option)|                |  endpoint  |
             |  prefix | code |         |                |   suffix   |
             |         |      |         |                | (10...00)  |
             |    G    |   F  |    S    |        I       |     H      |
             |_________|______|_________|________________|____________|
                    _______/   <-- s ---><----- i ------>
                  /               ^                    ^
                 v                |                    |
        Specifies s and b        /                      \
          (option)              |                        \
        Specify F   <-----.-----|--------------------.    \
                           \    |                     \    |
                            \   v                      \   v
                           <-- s --->                 <----- i ------>|
              ________________________________________________________
             |local-address| Subnet  |  next field   |     branch     |
             |   constant  |  index  |   Delimiter   |      index     |
             |    Prefix   |         |   (00...01)   |                |
             |             |         |               |                |
             |       P     |    S    |      D        |        I       |
             |_____________|_________|_______________|________________|
             |<-- subnet prefix zS -->
             |<-------------- Branch local address B ---------------->|


         SAM GLOBAL PREFIXES - GLOBAL ADDRESSES - LOCAL ADDRESSES

                                 Figure 4

   Principles that influence the internal structure of branch
   identifiers proposed for SAM are the following:

   1.  To permit a flexible hierarchy of local zones, branch identifiers
       should be kept rather short.  They should, at least to some
       extent, be proportionate to the maximum number of branches
       supported in their zone.

   2.  Several subnets must be possible in the zone.  For this, a branch
       identifier contain an optional "subnet index" (S), followed the
       "branch index" (I) which identifies the branch in its subnet.
       (The word "index" is chosen to express that these fields have no
       further internal structure.)



Despres                    Expires May 5, 2009                 [Page 10]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


   3.  For the efficiency of routing tables, intra-zone subnet indexes
       have to be in the upper part of local addresses, just behind the
       "constant prefix" (P) that is common to all local addresses.  (In
       IPv6, this constant prefix can typically be an ULA prefix of
       [RFC4193]; in IPv4 is typically a private-address prefix of
       [RFC1918].)

   4.  For efficiency of the neighbor discovery protocol of [RFC2461],
       branch indexes B have on the contrary to be in the lowest part of
       branch local addresses B.

   5.  Consequently, it must be possible to extract separately, from a
       intra-zone branch identifier iB, the subnet index S and the
       interface index I, and for this to know their lengths (s and i).

   6.  In order to permit to configure several subnet-index lengths,
       and/or several interface index lengths, in SAM zones, an optional
       branch-identifier "format code" (F) is placed at the beginning of
       branch identifiers B (just before the optional subnet index S,
       and the branch index B).  Each format codes specifies a subnet-
       index length s and an interface-index length i.  Format codes T
       may have different lengths, but must be non overlapping prefixes
       to be recognized.

   Since the local address B of a branch interface starts with a
   constant prefix P followed by the interface subnet index S , and is
   terminated by the interface-index of the interface, space is left
   between them.  It is filled with a next-field delimiter (D).  Its
   format, a series of 0s followed by a 1, i.e. 00...01 with a minimal
   length of 1 bit, is chosen so that knowing the constant prefix P and
   the subnet prefix of a branch interface, lengths s and i of the its
   subnet index S and of its interface index I can be determined.  Then,
   the identifier format F to be placed in global prefixes of B can be
   derived from these lengths s and i.

3.4.  Endpoint global address to branch local address mapping

   Detailed steps by which a branch local address B is derived from from
   the global address of a branch-side endpoint are presented in
   Figure 5.











Despres                    Expires May 5, 2009                 [Page 11]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


              ________________________________________________________
             |                  Endpoint Global address               |
             |                             gE                         |
             |________________________________________________________|
                           (A) ANALYSIS    ||
                                           \/
              ___________________________________________ ............
             | Global  |  id  |  Subnet |     branch     | endpoint   :
             | prefix  |Format|  index  |      Index     |  suffix    :
             |    G    |   F  |    S    |        I       |     E      :
             |_________|______|_________|________________|............:
                       |   |       |            |
     1. Match found    |   |       |            |
     in the G list  ___|   |       |            |
                           |       |            |
     2. Match found        |       |            |
     in the F list   ______|       |            |
                                   |            |
     3. length defined by F _______|            |
                                   .            |
     4. length defined by F ____________________|
                                   .            .
                 (B) CONSTRUCTION  .     ||     .
                                   .     \/     .
     5. The current                .            .
     local-address prefix __       .            .
                            |      .            .
     6. From step 3. _______:______.__          .
                            |         |         .
     7. From step 4. _______:_________:_________.__________
                            |         |                    |
     8. Binary 00...01 _____:_________:________            |
                            |         |        |           |
              ______________|_________|________|___________|__________
             |  local-address  | Subnet  |next field |     branch     |
             |     Prefix      |  index  | Delimiter |      Index     |
             |         P       |    S    |    D      |        I       |
             |_________________|_________|___________|________________|
             |<--------------- Branch Local address B --------------->|

        DERIVING A BRANCH LOCAL ADDRESS FROM AN ENDPOINT GLOBAL ADDRESS

                                 Figure 5








Despres                    Expires May 5, 2009                 [Page 12]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


3.5.  Privacy protection

   In a zone where privacy protection is desired, the privacy option can
   be turned on.  Principles of this option are the following:

   o  Fields that identify branch-side IP endpoints in privacy protected
      zones, or transport endpoints if endpoints are at this layer, are
      obfuscated in e2e packets that traverse the the global Internet.

   o  This obfuscation is stateless and reversible.

   o  Branch SAMs of a privacy-protected zone are informed of parameters
      of this obfuscation.  They can thus know which "hidden" addresses
      (or addresses plus ports), appear on the global Internet in place
      of their "clear" addresses (or address plus ports).  These clear
      addresses are those from which local addresses are derived in the
      privacy-protected zone and in zones that are lower in the
      hierarchy.

   o  In these lower zones, all branch SAMs are informed that a root SAM
      in the global-Internet direction has activated a privacy option,
      and are informed of parameters of this option.  They can thus
      derive a clear address (or address plus port) from an obfuscated
      address (or address plus port), and conversely.  They can also
      avoid to activate the privacy so that obfuscation is never done
      more than once.

   Parameters of a privacy option are a privacy global prefix (PPm) and
   a scrambling multiplier (PMm).  The prefix is that which, at the
   beginning of global addresses, is not obfuscated in the global
   Internet.  The multiplier is a 64 bit odd constant.

   Obfuscation consists in a modulo 2^n multiplication by the scrambling
   multiplier, where n is the number of bits to be obfuscated.  De-
   obfuscation is the modulo 2^n multiplication by the inverse of the
   scrambling multiplier (for odd numbers, such an inverse modulo 2^n
   always exists).

   In hosts in which the branch SAM is informed of an active privacy
   option, applications that ask for their address and their port at
   their socket interface, get them in hidden form, that which appears
   in the global Internet.  The e2e principle is thus preserved despite
   the fact that the topology of the privacy-protected zone and that of
   lower zones in the hierarchy are all hidden, and despite the fact
   that successive transport connections from a same host cannot, in the
   global Internet, be related to a single host.

   Ports that are concerned with the privacy option are only the IANA



Despres                    Expires May 5, 2009                 [Page 13]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


   defined dynamic and/or private ports (ports 49152 to 65535, those
   starting with binary 11).  Well known ports and registered ports,
   which have an e2e meaning not to be lost must not be obfuscated.

   Since some applications, e.g. active mode FTP of [RFC0959], work on
   port pairs rather than on individual ports, port bits to be
   obfuscated must exclude the las one.  Port bits that are part of
   obfuscated endpoint identifiers are then bits 2 to 14.



                                            gY
                                             ^
                                             |
                                            ...
    e2e packet:              gZ11.F2.hhhh->gY [TCP hh->80 [data]]
                                             ^
                                             |
                                           gZkij         ROOT ZONE R
                  ___________________________:________________________
                 |(Z)             .--> (root SAM)                     |
    Privacy-option ON            /           Rk                       |
    for prefix PP1 = gZkij.F1 ---'           ^          LOCAL ZONE Z  |
    with multiplier PM1                      |                        |
                 |                           |                        |
                 |                          ...                       |
    encapsulated |   [ B->R [ gZkij.cccc->gY [TCP cc->80 [data]]      |
       packet    |                                                    |
                 |                           ^                        |
                 |                           |                        |
                 |                           B                        |
                 |___________________________:________________________|
                                        (branch SAM)
    Clear-address packet:        gZkij.F1.cccc->gY [TCP cc->80 [data]]
    e2e packet:                  gZkij.F1.hhhh->gY [TCP hh->80 [data]]
       where tmp = modulo 2^m (PM1 x (cccc . (bits 2 to 14 of cc))
                   where m = length of cccc + length of cc - 3
             hhhh = bits 0 to (length of hhhh - 1) of tmp
             hh = cc in which bits 2-15 are replaced by
                  bits(length of PP1 TO m - 1) of tmp .

                           SAM PRIVACY OPTION ILLUSTRATION

                                 Figure 6

   Figure 6 illustrates the effect of the privacy option.  The option is
   supposed to be on, in the root SAM of the zone, for its global prefix
   gZkij and its identifier format F1.  The privacy-option prefix is



Despres                    Expires May 5, 2009                 [Page 14]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


   therefore PP1 = gZ11.F2. the scrambling multiplie ris PM1.

3.6.  SAM parameters

   Table 3 to Table 5 of this section present the complete set of SAM
   parameters described in previous sections.

                      +-----------------------+-----+
                      | constant local Prefix | TTL |
                      +-----------------------+-----+
                      |          ...          | ... |
                      |           Pm          | PTm |
                      |          ...          | ... |
                      +-----------------------+-----+

                        CONSTANT PREFIX PARAMETERS

                                  Table 1

   +--------------------+-----+------------------+---------------------+
   |  identifier Format | TTL |   Subnet-index   |   Interface-index   |
   |        code        |     |      Length      |        Length       |
   +--------------------+-----+------------------+---------------------+
   |         ...        | ... |        ...       |         ...         |
   |         Fn         | FTn |        SLn       |         ILn         |
   |         ...        | ... |        ...       |         ...         |
   +--------------------+-----+------------------+---------------------+

                       IDENTIFIER-FORMAT PARAMETERS

                                  Table 2

   +-----------------+-----+---------------+-----+---------------+-----+
   |    Root local   | TTL | Global Prefix | ... | Global Prefix | ... |
   |     address     |     |       1       |     |       j       |     |
   +-----------------+-----+---------------+-----+---------------+-----+
   |       ...       | ... |      ...      | ... |      ...      | ... |
   |        Ri       | RTi |      gZi1     | ... |      gZij     | ... |
   |       ...       | ... |      ...      | ... |      ...      | ... |
   +-----------------+-----+---------------+-----+---------------+-----+

                              ROOT PARAMETERS

                                  Table 3







Despres                    Expires May 5, 2009                 [Page 15]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


                       +--------------------+------+
                       | Global zone prefix |  TTL |
                       +--------------------+------+
                       |         ...        |  ... |
                       |        gZij        | GTij |
                       |         ...        |  ... |
                       +--------------------+------+

                         GLOBAL-PREFIX PARAMETERS

                                  Table 4

        +-----------------------+-----+---------------------------+
        | Privacy-option Prefix | TTL | Privacy-option Multiplier |
        +-----------------------+-----+---------------------------+
        |          ...          | ... |            ...            |
        |          PPp          | PTp |            PMp            |
        |          ...          | ... |            ...            |
        +-----------------------+-----+---------------------------+

                         PRIVACY-OPTION PARAMETERS

                                  Table 5

3.7.  Port-range-based extended IPv4 addressing

   For a dual stack host not to break the e2e principle when it
   establishes a connection with an remote endpoint that is still only
   reachable in IPv4, it must have a global IPv4 address.  Because of
   the IPv4 address shortage, this address may however be shared with
   other hosts.  For this, SAM accepts "port-extended" IPv4 prefixes,
   longer than 32 bits.  Bits beyond the first 32 define a port range in
   the set of dynamic and/or private ports (those in which the two high
   order bits are binary 11).  For example, a 3-bit prefix extension 010
   imposes that branch-side hosts use only ports starting with binary
   11010.

   Note that, due to the systematic encapsulation of global packets in
   local packets of SAM, routing within SAM zones is not concerned with
   theses "port-extended" IPv4 addresses.  Only root SAMs and branch
   SAMs have to know about of port ranges.

   The branch SAM in a host that is assigned a port-restricted IPv4
   address has to inform its socket interface of the port range
   available to applications, and to inform its internal NAT if it has
   one.  Consequences for applications, and for NATs, of restricted port
   ranges, are out of the scope of this SAM specification.  Other
   documents are available on the subject, e.g.  [Boucadair], which



Despres                    Expires May 5, 2009                 [Page 16]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


   however requires further study.


4.  SAM Application examples

4.1.  Address independence in an IPv6 site

   In the example of Figure 7, we consider a home or SOHO site in which
   an Ethernet and/or WiFi LAN is deployed.  Its global IPv6 prefix gZ
   is 2001:0db8:9999::/48.

   Local addressing is done in an IPv6 private space.  To keep address
   shorts in the figure, the constant prefix of these addresses is
   fc00/8, the shortest prefix reserved for private IPv6 addressing in
   [RFC4193].  (This prefix could however be replaced by a full fdxx:
   xxxx:xxxx::/48 prefix, as recommended in [RFC4193] for ULAs, without
   changing the substance of the example.)

   The site is configured to support 255 branch interfaces on the LAN
   (each branch being indifferently a host and/or a router).  To
   facilitate future changes, a branch-identifier format code F1, set to
   0/4, is used in branch global prefixes.

   SAM parameters of the site are then following (ignoring TTLs):

      Constant local prefix: P1 = fc00/8

      Identifier format code: F1 = 0::/4

      Subnet index length: SL1 = 0 (non applicable)

      Interface index length: IL1 = 8

      Root local address: R1 = fc00::0101

      Zone Global prefix: gZ11 = 2001:0db8:9999::/48

      Privacy option prefix: none in this example

   We now consider a SAM-capable PC which serves as a router for a
   bluetooth link.  On this link, a bluetooth mobile phone is active.
   (Configuring a root-SAM in the PC would permit the mobile phone, if
   acting as a SAM-capable router, to assign global prefixes and
   addresses, to hosts behind it.  But this would have been too much for
   the example).






Despres                    Expires May 5, 2009                 [Page 17]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


                                          |
                                          |
                                  2001:0db8:9999::/48
                         _________________:_________________
                        |(Z)       (root SAM) for 2^8 hosts |
                Site    |            fc00::0101             |
               gateway  |                                   |
                        |                                   |
                        |            fc00::0155             |
                        |_________________:_________________|
                                          |
                 Ethernet and/or WiFi    ...
                      fcOO::/64           |

                                      fc00::0155
                                     (branch SAM)
                             => +  2001:0db8:9999:0550::/60
                                __________:__________
                               |2001:0db8:9999:0558::|
               PC              |                     |
                               |_____________________|
                              /___________._________/
                                          |
                  Bluetooth              ...
               2001:0db8:9999:0550::/64   |
                                          |
                            2001:0db8:9999:0550:< eui64 IID >
                                          |
                                        |_|__
                                       |     |
               Mobile phone            |     |
                                       |     |
                                       |_____|

                                 Figure 7

   The PC local address B is fc00::0155, i.e.  P.D.I where P is
   fc00::/8, where the 8 bits of I are supposed to be 55::/8, and where
   D is binary 00...01 with consequently (128 - 8 -8) = 112 bits.

   The PC global prefix gB is therefore 2001:0db8:9999:0550::/60, i.e.
   G.F.I, where G is 2001:0db8:9999::/48, where F is 0::/4, and where I
   is 55::/8.

   The PC global address is therefore 2001:0db8:9999:0558::, i.e. gB.E
   where E is binary 10...00 with (128 - 48 - 4 - 8) = 68 bits.

   The bluetooth link is supposed to have 0::/4 as subnet ID in the PC.



Despres                    Expires May 5, 2009                 [Page 18]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


   Its /64 subnet prefix is therefore 2001:0db8:9999:0550::/64.

   This simple example illustrates how the SAM logic permits to
   establish a hierarchy of routing zones where each host can become a
   router, and where the e2e principle is preserved.

4.2.  Multihoming and extended IPv4 addressing in a home site

   In the example of Figure 8, we consider a home site S, multihomed
   with two ISPs A and B.

   ISP A assigns to the site IPv6 prefix 2001:1111:1111:1110::/60, and
   IPv4 address 192.0.2.1.

   ISP B can only assign port-restricted IPv4 addresses to its sites
   because it has to support up to 2^16 sites, and has only for this an
   IPv4 /18 prefix (namely 198.16.0.0/18, i.e. v4|c610:0000:/18), and
   since 18 + 16 = 34 which exceeds 32.  Having 2001:0db8::/32 as its
   IPv6 prefix, it assigns /48s to its customer sites, in particular
   2001:0db8:0202::/48 to site S.

   Half of its IPv4 address space, namely v4|c608:c000/19 is allocated
   to a NAT to support sites that are not SAM capable.  The other half,
   i.e. v4|c610:2000/19, is allocated to a root SAM, the local address
   of which is supposed to be 2001:0db8::1.

   SAM parameters of the zone of ISP B are then the following:

      Constant local prefix: P1 = 2001:0db8: = v4|a000::/8

      Identifier format code: F1 = ::/0 (non applicable)

      Subnet index length: SL1 = 0 (non applicable)

      Interface index length: IL1 = 16

      Root local address: R1 = 2001:0db8::1:1

      Zone Global prefix: gZ11 = v4|c608:8000/19 (=198.8.128.0/19).

      Privacy option prefix: none in this example (::/0)










Despres                    Expires May 5, 2009                 [Page 19]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


                                                      198.16.0.0/18
                                2001:0db8::/32       =v4|c610:0000:/18
                                  ____|__________________|____________
                                 |(B)             /            \      |
                                 |               |    v4|c610:2000/19 |
                                 |          v4|c608:c000/19      |    |
                                 |             (NAT)       (root SAM) |
                                 |         0.0.0.0/0     2001:0db8::1 |
     |(A)                     |  |                                    |
     |                        |  |                                    |
     |2001:1111:1111:1110::/60|  |   (2^16 SAM sites)                 |
     |       192.0.2.1        |  |                                    |
     |      =v4|c000:0201/32  |  |      2001:0db8:0202::/48           |
     |________________:_______|  |___________________:________________|
                      |                      (branch SAM)
                      |           => + v4|c610:2040:4000::/35
                      |              = 198.8.128.64/ports 11010...
      ________________:______________________________:________________
     |(S)     /               \               /              \        |
     |       |     v4|c000:0201:0000::/33    |  v4|c610:2040:4000::/36|
     |       |                 ::/0          |                 ::/0   |
     | v4|c600:0201:8000::/33   |     v4|c608:2040:6000::/36    |     |
     |     (NAT)            (root SAM)     (NAT)          (root SAM)  |
     |   0.0.0.0/0          fc00::0011    0.0.0.0/0       fc00::0012  |
     |                                                                |
     | (2^4 SAM hosts)                                                |
     |                        fc00::0018                              |
     |_____________________________:__________________________________|
                                   |
           HOST (H)           (branch SAM)
                    => + 2001:1111:1111:1118:8000::0008/64
                       + 2001:0db8:0220:4800::0008/52
           + v4|c000:0201:4000::/37 = 192.0.2.1 ports 1101000...
           + v4|c610:2040:5000::/40 = 198.16.32.64 ports 1101001000...
                                  :
                                  HOST

       PRIVATE-ADDRESSING- AND DUAL-HOMING- SITE WITH E2E CAPABILITY

                                 Figure 8

   In site S, the branch SAM of its root interface with ISP B derives
   from its IPv6 prefix 2001:0db8:O2O2::/48, and from SAM parameters of
   ISP B, its IPv4 prefix v4|c610:2040:4000::/35, which is a port-
   restricted one.

   Two root SAMs are configured in site S. Its local-address constant
   prefix is fc00::/8 as.  Half of the each available IPv4 addressing



Despres                    Expires May 5, 2009                 [Page 20]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


   space is reserved for a NAT, and the other half for a root SAM.

   Parameters of SAMs of site S are then the following:

      Constant local prefix: P1 = fc00/8

      Identifier format code: F1 = 0::/4

      Subnet index length: SL1 = 0

      Interface index length: IL1 = 8

      Root local addresses: R1 = fc00::0011; R2 = fc00::0012

      Zone Global prefixes: gZ11 = 2001:1111:1111:1110::/60; gZ12 = v4|
      c000:0201/32; gz21 = 2001:0db8:0202::/48; gZ22 = v4|
      c610:2040:4000::/35

      Privacy option prefix: none in this example (::/0)

   Among the 16 hosts of home site S, Host H is supposed to have local
   address fc00::0018.  As shown on the figure, the branch SAM of host H
   then derives from this local address two IPv6 global prefixes, two
   IPv6 global host addresses starting with these prefixes, and two
   port-restricted IPv4 prefixes.  With these prefixes, it can use,
   without breaking the e2e principle, 512 ports for connections via ISP
   A, and 64 ports via ISP B.


5.  SAM as an alternative to NATs in IPv6

   With SAM as specified, all NAT44 services that have been listed in
   Section 2 can be offered in IPv6 without stateful processing and
   without breaking the e2e principle:

   1.  In a private-addressing IPv6 site, hosts can know their global
       addresses to use them in e2e packets that are encapsulated in
       local packets to traverse the site.  Renumbering is then
       automated simply by automating advertisement of SAM parameter
       changes (in DHCP and/or with router advertisements).

   2.  The fact that NAT44s are in general configured with by default
       rejection of all incoming calls can have a simple stateless
       equivalent in IPv6:

       *  By default, reject all incoming packets that have a branch-
          side port in the well known or in the IANA defined registered
          port ranges.



Despres                    Expires May 5, 2009                 [Page 21]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


       *  By default, reject all TCP incoming packets that are attempts
          to open new incoming connections (SYN packets without ACK).

   3.  In a SAM-capable site, SAM-capable hosts can take advantage of
       site multihoming with full compatibility with ingress filtering
       of [RFC3704] in both the site itself and in ISP networks to which
       it is connected.

   4.  The privacy protection described in Section 3.5 maintains the e2e
       principle.  It is expected to be largely sufficient in practice.
       (Sophisticated hackers would probably find ways around it, and
       identify who does what in sites havin the privacy-protection
       option, but NAT44s are not perfect for privacy protection
       either).

   5.  As we have seen, SAM global addresses contain a flexible
       succession of branch identifiers, so that it becomes possible to
       set up a flexible hierarchy of private addressing zones.  In
       particular, host-rooted subnets become possible without breaking
       the e2e principle.

   For information, no intellectual property right has been applied for
   by the author on any of SAM mechanisms.  The intent is to facilitate
   IPv6 deployment with new mechanisms that still enhance its potential.


6.  Security considerations

   Like any function where some parameters have to be configured, SAM
   introduces a risk of human errors.

   Besides that, no security risk introduced by SAM has so far been
   identified.  In particular:

   Provided consistency between local addresses present in encapsulating
   packets and global addresses present in encapsulated packets are
   systematic, no more address spoofing is possible than without SAM.

   Due to the stateless operation of SAM, its scalability is high.
   Prevention against denial of service attacks should therefore remain
   easy even for very intense traffic (e.g. using load balancers in
   front of parallel devices).


7.  IANA Considerations

   If and when this specification is stabilized and approved, option
   codes in DHCP, DHCPv6, and ND will have to be defined to



Despres                    Expires May 5, 2009                 [Page 22]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


   automatically convey SAM parameters to branch SAMs.


8.  Acknowledgements

   As this specification has evolved during many months, precious
   encouragement and remarks were received from Mark Townsley.  He has
   to be warmly thanked for it.  Concerning what SAM can bring to port-
   restricted IPv4 addresses, stimulating discussions with Dan Wing,
   Teemu Savolainen, Gabor Bajko, Pierre Levis, Jean-Luc Grimault, and
   Alain Villefranque, have influenced progress of the work.  Gratitude
   is due to them for this.  Challenging remarks, and a few (deserved)
   criticisms from Alain Durand have also helped to better analyze how
   SAM will coexist with NATs.  He deserves credit for it.


9.  References

9.1.  Normative References

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

9.2.  Informative References

   [6rd]      Despres, R., "IPv6 Rapid Deployment on IPv4
              infrastructures (6rd) - Work in progress
              (draft-despres-6rd-02)", October 2008.

   [Boucadair]
              Boucadair, M., Grimault, J-L., Levis, P., and A.
              Villefranque, "Behaviour of BitTorrent service in an IP
              Shared Address Environment



Despres                    Expires May 5, 2009                 [Page 23]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


              (draft-boucadair-behave-bittorrent-portrange-02 - work in
              progress)", january 2009.

   [LISP]     Farinaci, D., Fuller, V., Oran, D., Meyer, D., and S.
              Brim, "Locator/ID Separation Protocol (LISP) -
              draft-farinacci-lisp-09", December 2008.

   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol",
              STD 9, RFC 959, October 1985.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3286]  Ong, L. and J. Yoakum, "An Introduction to the Stream
              Control Transmission Protocol (SCTP)", RFC 3286, May 2002.

   [RFC3582]  Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
              Multihoming Architectures", RFC 3582, August 2003.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

   [RFC4219]  Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers
              Should Think About", RFC 4219, October 2005.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4864]  Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
              E. Klein, "Local Network Protection for IPv6", RFC 4864,
              May 2007.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

   [Shim6]    Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming



Despres                    Expires May 5, 2009                 [Page 24]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


              Shim Protocol for IPv6 - Work in progress
              (draft-ietf-shim6-failure-detection-09)", October 2007.

   [draft-carpenter-renum-needs-work-01]
              Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
              still needs work - Work in progress", December 2008.

   [shim6 fail detec]
              Arkko, J. and I. van Beijnum, "Failure Detection and
              Locator Pair Exploration Protocol for IPv6 Multihoming -
              Work in progress (draft-ietf-shim6-failure-detection-09)",
              July 2007.


Author's Address

   Remi Despres
   3 rue du President Wilson
   Levallois,
   France

   Email: remi.despres@free.fr





























Despres                    Expires May 5, 2009                 [Page 25]


Internet-Draft     Stateless  Address  Mapping  (SAM)      November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Despres                    Expires May 5, 2009                 [Page 26]

 From brian.e.carpenter@gmail.com Sun Mar 15 18:34: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 1B2AB3A6BA9 for ; Sun, 15 Mar 2009 18:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 gdPa3PvJCP+U for ; Sun, 15 Mar 2009 18:34:54 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 439DA3A68C3 for ; Sun, 15 Mar 2009 18:34:54 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id l9so2551599rvb.49 for ; Sun, 15 Mar 2009 18:35:35 -0700 (PDT) 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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=c4FF+cJO13XpQ0GgDpUu5BOjatViWUDFah44/AVzkyc=; b=diwnjb3R9FITGhQYgQT9gYHK7jF8h10sCsXNaaSjGDxwQ3Mt8t/u/27DL8YAd2TYdR tX0JX0YzmOO30OLZ+uS/0MsWkC25WlT1f3g3h42SVPdNXxfkZ/QBm8jr/2yomhZa2dMN lZXgtxru1q3vWYRhLe18v7/i0NWpBr70T72AI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=DAzxhDu3cvdlp0rBcw13Bj6Yi4sUKcR4SanbP+ykqZWrW0GcYL0gJtfUHMBJ+wZvqX Js98vF5+qmFc/O2S2VmXFS1e1p5CzHx4rD3OwqSI1UVJbqW08lFk1a10yiiOmQqcuCbD 1U8BkOoe0kN54c6KuD43tX4PmJQgAlvGIhopw= Received: by 10.140.193.15 with SMTP id q15mr1939318rvf.78.1237167335777; Sun, 15 Mar 2009 18:35:35 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k2sm15169521rvb.4.2009.03.15.18.35.34 (version=SSLv3 cipher=RC4-MD5); Sun, 15 Mar 2009 18:35:35 -0700 (PDT) Message-ID: <49BDACE3.2090907@gmail.com> Date: Mon, 16 Mar 2009 14:35:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: behave@ietf.org References: <20090224184501.519513A690D@core3.amsl.com> In-Reply-To: <20090224184501.519513A690D@core3.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-baker-behave-v4v6-framework-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, 16 Mar 2009 01:34:55 -0000 > 2.2.1.1.4. DNS ALG configuration > > For the DNS ALG configuration in the stateless mode, the IVI6 hosts > know the PREFIX, therefore, DNS ALG can be implemented in the end- > system without additional information. I'm quite confused. There are many references to the phrase "DNS ALG" or "DNS-ALG" in the draft, but the function that's actually described (in 2.2.1.2.3 and 2.2.1.2.4) is a DNS synthesizer in the spirit of DNS64, also referred to as a DNS Translator in 2.3.1. That seems to be quite different from the DNS ALG defined for NAT-PT. Can you clarify the terminology in this area, and use it systematically? Brian From xing@cernet.edu.cn Mon Mar 16 07:10: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 C048728C0EB for ; Mon, 16 Mar 2009 07:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[AWL=-1.348, 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 sgoXQL7hOmEL for ; Mon, 16 Mar 2009 07:10:52 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id E6B2928C121 for ; Mon, 16 Mar 2009 07:10:49 -0700 (PDT) Received: from [127.0.0.1]([123.112.78.244]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jma49be9313; Mon, 16 Mar 2009 22:11:28 +0800 Message-ID: <49BE5E07.4040809@cernet.edu.cn> Date: Mon, 16 Mar 2009 22:11:19 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Brian E Carpenter References: <20090224184501.519513A690D@core3.amsl.com> <49BDACE3.2090907@gmail.com> In-Reply-To: <49BDACE3.2090907@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: thW7NjVB Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-baker-behave-v4v6-framework-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, 16 Mar 2009 14:10:53 -0000 Brian E Carpenter 写é“: >> 2.2.1.1.4. DNS ALG configuration >> >> For the DNS ALG configuration in the stateless mode, the IVI6 hosts >> know the PREFIX, therefore, DNS ALG can be implemented in the end- >> system without additional information. >> > > > I'm quite confused. There are many references to the phrase > "DNS ALG" or "DNS-ALG" in the draft, but the function that's actually > described (in 2.2.1.2.3 and 2.2.1.2.4) is a DNS synthesizer in the spirit > of DNS64, also referred to as a DNS Translator in 2.3.1. That seems to be > quite different from the DNS ALG defined for NAT-PT. > > Can you clarify the terminology in this area, and use it systematically? > The DNS-ALG and the DNS translator in the framework draft performing the functions of DNS64. We will change the name in the next version. Thanks. xing > Brian > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From mrw@lilacglade.org Mon Mar 16 17: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 5C8B53A69E5 for ; Mon, 16 Mar 2009 17:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, J_CHICKENPOX_22=0.6, J_CHICKENPOX_46=0.6, 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 DjvRciF8fePr for ; Mon, 16 Mar 2009 17:12:31 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 7ECFE28C196 for ; Mon, 16 Mar 2009 17:12:30 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA09.westchester.pa.mail.comcast.net with comcast id Topk1b0070cZkys590DDgu; Tue, 17 Mar 2009 00:13:13 +0000 Received: from [10.36.0.45] ([76.119.58.152]) by OMTA10.westchester.pa.mail.comcast.net with comcast id U0DC1b0083H3vh03W0DCpS; Tue, 17 Mar 2009 00:13:13 +0000 Message-Id: <96B651AC-8244-44DF-8937-2FB79C119B49@lilacglade.org> From: Margaret Wasserman To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <49BA2DD6.8080001@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Mar 2009 20:13:10 -0400 References: <49BA2DD6.8080001@free.fr> X-Mailer: Apple Mail (2.930.3) Cc: Softwires WG , Behave WG , Internet Area Subject: Re: [BEHAVE] FYI: draft-despres-sam-02 enclosed X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2009 00:12:44 -0000 Hi Remi, I have a few high-level comments/questions on this draft from my first =20= reading, and I may have more after I have reviewed it in more detail. (1) You have indicated that you would like to discuss this draft in =20 the 6AI BOF, but you have not cc:ed the mailing list for the 6AI BOF = (nat66@ietf.org=20 ). Also, have you talked to the chairs of the 6AI BOF (Bob Hinden and =20= Dan Wing) about whether they are willing to include this draft on the =20= agenda, despite the fact that it has not been posted to the I-D =20 archive? There doesn't appear to be an agenda online for the 6AI BOF =20= yet, so I am not sure if it will be included. (2) The end hosts in the SAM system need to know their globally =20 routable addresses, so how can SAM be said to provide address =20 independence? (3) Exactly what formulation of the end-to-end principle are you =20 referring to in this paper when you indicate that SAM preserves it in =20= IPv6? My understanding of the end-to-end principle is that it has to do with =20= putting intelligence at the edges of the network (in hosts vs. routers/=20= middleboxes) and with putting certain function at the top of the =20 protocol stack (apps layer vs. lower layers). This is based on my =20 understanding (and recollection) of a paper by Jerry Saltzer, D. Reed =20= and Dave Clark written in the mid 1980s, which you can find here: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt It is also reasonably well-summarized in this Wikipedia article. http://en.wikipedia.org/wiki/End-to-end_principle Based on my understanding of the end-to-end principle, I don't see any =20= significant difference in SAM vs. NAT66 WRT how much they maintain (or =20= violate) the end-to-end principle, as both mechanisms place some =20 functions/intelligence in the infrastructure. Margaret On Mar 13, 2009, at 5:56 AM, R=E9mi Despr=E9s wrote: > Hi, > For your information, draft-despres-sam-02, which was ready too late =20= > to be posted before IETF 74, is enclosed below > > It is a major update of the version-01 which was presented at IETF 73: > - In Softwires, ref.: > = http://www.ietf.org/proceedings/08nov/slides/softwire-3/softwire-3_files/s= lide0002.htm > - In Behave, ref.: > http://www.ietf.org/proceedings/08nov/slides/behave-15.pdf > > In San Francisco, its part that deals with NAT66 avoidance is to be =20= > discussed at the 6IA BOF meeting (ex NAT66). > Its part that deals with Port-Range extension, is to be discussed at =20= > the SHARA BOF. > > Comments most welcome. > > Regards, > > RD > > > > > > > Internet Engineering Task Force R. =20 > Despres > Internet-Draft November =20= > 2008 > Intended status: Standards Track > Expires: May 5, 2009 > > > Stateless Address Mapping (SAM) > Avoiding NATs and restoring the end-to-end principle in IPv6 > draft-despres-sam-02 > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of 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 =20 > months > and may be updated, replaced, or obsoleted by other documents at =20= > 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 May 5, 2009. > > Abstract > > Stateless Address Mapping (SAM) is a generic mechanism to support > global addressing across network zones where routing is based on a > different address space. With it, the end-to-end principle, lost =20= > in > IPv4 with the deployment of NATs, can be restored without losing > services that NAT44s offer beyond address-space extension (private > addressing, basic firewall, site multihoming, privacy protection, > host-rooted subnets). Global-address packets are encapsulated in > local-address packets to traverse SAM zones, and global prefixes =20= > are > statelessly mapped into local addresses. For the IPv6-IPv4 > coexistence period, port-restricted IPv4 addresses are used to =20 > extend > the global IPv4 address space. > > > > Despres Expires May 5, 2009 =20 > [Page 1] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > Table of Contents > > 1. Introduction and general problem =20 > statement . . . . . . . . . . 3 > 2. NAT44 services availability of which in IPv6 is =20 > desirable . . 4 > 2.1. Private addressing (easy =20 > renumbering) . . . . . . . . . . 4 > 2.2. Basic firewall (by default, no incoming =20 > connections) . . . 4 > 2.3. Site multihoming (automatic =20 > fallback) . . . . . . . . . . 4 > 2.4. Privacy =20 > protection . . . . . . . . . . . . . . . . . . . . 4 > 2.5. Host-rooted =20 > subnets . . . . . . . . . . . . . . . . . . . 5 > 3. SAM =20 > specification . . . . . . . . . . . . . . . . . . . . . . 5 > 3.1. Local Zones - Root SAMs - Branch =20 > SAMs . . . . . . . . . . 5 > 3.2. Encapsulation of global packets in local =20 > packets . . . . . 7 > 3.3. Global prefixes - global addresses - local =20 > addresses . . . 9 > 3.4. Endpoint global address to branch local address =20 > mapping . 11 > 3.5. Privacy =20 > protection . . . . . . . . . . . . . . . . . . . . 13 > 3.6. SAM =20 > parameters . . . . . . . . . . . . . . . . . . . . . . 15 > 3.7. Port-range-based extended IPv4 =20 > addressing . . . . . . . . 16 > 4. SAM Application =20 > examples . . . . . . . . . . . . . . . . . . . 17 > 4.1. Address independence in an IPv6 =20 > site . . . . . . . . . . . 17 > 4.2. Multihoming and extended IPv4 addressing in a home =20 > site . 19 > 5. SAM as an alternative to NATs in =20 > IPv6 . . . . . . . . . . . . 21 > 6. Security =20 > considerations . . . . . . . . . . . . . . . . . . . 22 > 7. IANA =20 > Considerations . . . . . . . . . . . . . . . . . . . . . 22 > 8. =20 > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 > 9. =20 > References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 > 9.1. Normative =20 > References . . . . . . . . . . . . . . . . . . . 23 > 9.2. Informative =20 > References . . . . . . . . . . . . . . . . . . 23 > Author's =20 > Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 > Intellectual Property and Copyright =20 > Statements . . . . . . . . . . 26 > > > > > > > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > [Page 2] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > 1. Introduction and general problem statement > > In IPv4, Network Address Translations have been extensively =20 > deployed > (NAT44s). They are key to mitigate the IPv4 address shortage. But > they also offer various auxiliary services, described in Section 2: > private addressing, basic firewall, site multihoming, privacy > protection, host-rooted subnets. > > In counterpart to these auxiliary services, these NAT44s have > introduced two drawbacks: > > o Non compliance with the end-to-end principle of the Internet > (e2e). > > Negative consequences include incompatibility with the IPsec > security mechanism, and difficulties for hosts to know their > own global addresses, which they need for connection > redirections, for host referrals, and and, in sites having > several site entrance routers, for multihoming support > mechanisms like the SCTP of [RFC4960] and [Shim6]. > > o Stateful operation. > > Most NAT44s are in fact stateful NAPTs (ref. < xref > target=3D"RFC2663" />): to support more local addresses than =20= > they > have external addresses, they maintain per-transport-=20 > connection > states. Negative consequences include limited scalability, =20= > and > the risk of denial of service attacks that go with it, as =20 > well > as single points of failures. > > Since no global address shortage is in view in IPv6, the following > questions have to be asked: > > o Which NAT44 services can, in IPv6, be offered statelessly and > without breaking the e2e principle? > > o How? > > This draft proposes to answer these questions more completely, and > with more technical details, than [RFC4864], the most advance > document on the subject so far. > > For this, a Stateless Address Mapping generic mechanism is =20 > introduced > (SAM). > > Conclusion, is that, provided SAM is supported in nodes at =20 > borders of > independently administered routing zones, the e2e principle can be > restored in IPv6, for all identified useful functions of NAT44s. > > > > Despres Expires May 5, 2009 =20 > [Page 3] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > (This conclusion needs however to be confirmed after further work =20= > on > SAM details, after criticisms by other experts, after some possible > bug corrections, and after validations with running code.) > > Thus, traversal of NATs in ISP infrastructures can be avoided. > (These NATs do provide useful connectivity to some non-SAM-capable > nodes, but have the drawback of breaking the e2e principle, with =20= > the > mentioned consequences on security, referrals, multihoming, > scalability and reliability. > > > 2. NAT44 services availability of which in IPv6 is desirable > > 2.1. Private addressing (easy renumbering) > > With NAT44s, when a prefix assigned by an ISPs to a customer site =20= > is > modified, local IP addresses in the site can remain unchanged. > > 2.2. Basic firewall (by default, no incoming connections) > > Most NAT44s, being NAPTs, and therefore maintaining states for all > TCP and UDP connections, have as a byproduct a protection against > incoming connections (unless some "holes" are "punched" in this > protection, under explicit customer control). This level of =20 > security > protection is largely relied upon. > > 2.3. Site multihoming (automatic fallback) > > In a site is multi-homed, and if it has a NAT device supporting all > its ISP interfaces, its hosts can take advantage of multihoming > without having to support any multihoming-specific function. This > level of multihoming support is better than none. > > (For this, a NAT44 needs only to make sure that, for each transport > connection, all outgoing packets go through the same ISP. Thus, if > an ISP access fails, current TCP and UDP connections that go via =20= > this > ISP are broken, but theycan immediately be replaced by new ones.) > > 2.4. Privacy protection > > =46rom outside a site where a NAT44 operates in NAPT mode, it is > difficult to determine which hosts establish which connections. =20= > This > level of privacy protection, in particular for some web requests, =20= > is > an added value. > > > > > > > > Despres Expires May 5, 2009 =20 > [Page 4] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > 2.5. Host-rooted subnets > > Behind a host that is assigned a single IPv4 address, it is =20 > possible, > with a NAT44 in the host, to deploy a private subnet. As modern > operating systems include a router function with a NAT44, a =20 > computer > can can serve as a root for a LAN. > > Thus, the distinction between hosts and a routers is no longer a > distinction between types of devices. It has become only a > distinction between functions within nodes. > > > 3. SAM specification > > 3.1. Local Zones - Root SAMs - Branch SAMs > > As presented in Figure 1, the SAM mechanism applies to a SAM "local > zone" Z. Routing within this zone is independently administered, =20= > and > is based on a "local address space". > > Each SAM zone has one or several "root interfaces" (Ri), that give > access to the global Internet. Each one has, in the global =20 > Internet, > one or several "global prefixes" (gZij) exclusively assigned to =20 > zone > Z. > > SAM global prefixes can be global IPv6 and/or global IPv4. SAM =20 > local > address spaces can be IPv6 or IPv4, global or private. If both =20 > IPv4 > and IPv6 are routed in the zone, one of the two is chosen for SAM. > (SAM is in this respect therefore an extension of the 6to4 of > [RFC3056], of the ISATAP of [RFC5214], and of [6rd], where all =20 > global > prefixes are IPv6 and all local address spaces are IPv4). > > As explained in Section 3.7, global IPv4 addresses can be extended > beyond 32 bits to deal with the IPv4 address shortage during the > IPv4-IPv6 coexistence period. > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > [Page 5] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > ROOT-SIDE ENDPOINTS > | /\ | > | || | > |_____:_____| || |______:_____| > | | > | ROOT ZONES | > | gZ22 > Zone Global prefixes gZij gZ11 gZ21 > Root interfaces: =20 > _________:_______________________:________ > |(Z) (root-SAM) (root-=20 > SAM) | > Root local addresses: | R1 =20 > R2 | > Ri =20 > | | > | SAM ZONE =20 > Z | > =20 > | | > =20 > | | > Branch local addresses: | B1 B2 =20 > B3 | > Bk =20 > | : : : | > Branch interfaces: |=20 > ______:________________:_____________:____| > | | | > Branch Global prefixes: | (branch-SAM) | > *gBkij=3DgZij.zBk* =3D> + gB211, gB221, gB222 > Branch Global Addresses: + gB211@, gB221@, gB222@ > *gBkij@=3DgBkij.H* || > BRANCH ZONES || > \/ > BRANCH-SIDE ENDPOINTS > > ROOT AND BRANCH INTERFACES AND SAMs > > Figure 1 > > Each root interface that supports a root-SAM function has a local > address (Rk), and each "branch interface" has a local address (Bk). > > If a "branch SAM" function is supported at a branch interface Bk, > this interface gets, in addition to its local address, global > prefixes (gBkij). Each of these prefixes is made of a global =20 > prefix > of the zone (gZij) followed by an identifier (zBk) of the branch in > its zone. > > For each each of its global prefixes gBkij, a branch interface has > also a host global address (gBkij@), derived from the prefix by > appending a standard host suffix (H) to complete the address =20 > length. > > Thus, if a zone D is accessible from the global Internet via a zone > hierarchy A, B, C, it has at least gA.aB.bC.cD as a global prefix =20= > gD, > and gA.aB.bC.cD.H as a global address gD@. SAM is thus an > application of the locator-identifier separation principle. (It > > > > Despres Expires May 5, 2009 =20 > [Page 6] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > differs however from [LISP], in that no new protocol is needed fro > SAM, just new options in existing protocols such as DHCP [RFC2131], > DHCPv6 [RFC3315], or ND [RFC4861], to advertise SAM parameters to > branch interfaces.) > > 3.2. Encapsulation of global packets in local packets > > > endpoint Y Global address: gY > ^ > | > ... > (3) e2e packet: [ gX->gY [data]] > ^ > | > gZ ROOT ZONE R > ______________:______________________ > |(Z) (root =20 > SAM) | > | R LOCAL ZONE =20= > Z | > | =20 > ^ | > | =20 > | | > =20 > | ... | > (2) encapsulated packet: =20 > | | > *B =3D la(gX)* | [ B->R [gX-=20 > >gY[data]] | > *R =3D parameter* | =20 > ^ | > | =20 > | | > | =20 > B | > |=20 > ______________:______________________| > (branch SAM) BRANCH ZONE B > =3D> + gB > ^ > | > ... > (1) e2e packet: [ gX->gY [data]] > ^ > | > endpoint X Global address: gX=3DgZ.id(B).xxx > > > PACKET ENCAPSULATION AND ADDRESS MAPPING - BRANCH SIDE TO ROOT =20= > SIDE > > Figure 2 > > To traverse a SAM local zone, global-address packets are =20 > encapsulated > into local address packets, as illustrated in Figure 2 and Figure =20= > 3). > > Thus, compatibility is ensured, within the local zone, with ingress > the filtering for multihomed networks of [RFC3704], the basic anti- > > > > Despres Expires May 5, 2009 =20 > [Page 7] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > spoofing mechanism. > > > | > | ROOT ZONE > gZ > ______________:______________________ > |(Z) (root-=20 > SAM) | > | R LOCAL ZONE =20= > Z | > =20 > | | > =20 > | | > =20 > | | > (2) encapsulated packet: | [ B1->B2 [gE1-=20 > >gE2[data]] | > *B1 =3D la(gX)* | --------=20 > >-------- | > *B2 =3D la(gY)* | / =20 > \ | > | ^ =20 > | | > | | =20 > v | > | B1 =20 > B2 | > |=20 > ______:_____________________:________| > BRANCH ZONES: (branch-SAM) (branch-SAM) > =3D> + gB1 =3D> + gB2 > ^ | > | v > (3) e2e packet: ... [ E1->E2 =20 > [data]] > (1) e2e packet: [ E1->E2 [data]] ... > ^ | > | v > gX=3DgZ.id(B1).xxx =20 > gY=3DgZ.id(B2).yyy > _:_ _:_ > | X | | Y | > |___| |___| > > ADDRESS MAPPING AND PACKET ENCAPSULATION - BRANCH SIDE TO BRANCH =20= > SIDE > > Figure 3 > > For the IP-in-IP encapsulation, the IPv6 next header or the IPv4 > protocol id which indicates the type of IP payload is set to 41 =20 > (the > same value as for 6to4, ISATAP, and 6rd). > > Local addresses are determined as follows (illustrated in figures > Figure 2 and Figure 3): > > 1. If an endpoint global address gE, indifferently source or > destination, is that of a branch-side endpoint, this is > recognized by the fact that it starts with one of the global > prefixes of the zone. Then, the local address B is obtained =20= > by a > function B=3Dla(gX), completely determined by SAM parameters of = =20 > the > > > > Despres Expires May 5, 2009 =20 > [Page 8] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > zone (details in Section 3.4). > > 2. If an endpoint global address gE, indifferently source or > destination, is that of a root-side endpoint, this is =20 > recognized > by the fact that it doesn't start with any of the global =20 > prefixes > of the zone. In this case, the other address gX of the packet, > destination or source respectively, is necessarily that of a > branch-side endpoint (otherwise the packet would not traverse =20= > the > local zone). Then, local address Ri is that of the root > interface that has, in its assigned global prefixes, the global > prefix present at the beginning of the branch-side address gX. > > In multihomed sites, the second of these rules ensures =20 > compatibility > with the ingress filtering of [RFC3704] in root zones (if it does > apply, as necessary for anti-spoofing protection). > > In Figure 2 and Figure 3, packets in the reverse direction, not > shown, would have the same addresses but with sources and > destinations inverted, and with encapsulations and decapsulations > made at inverted interfaces. > > Decapsulation functions MUST verify, for anti-spoofing protection, > that local addresses present in headers of encapsulating packets =20= > are > consistent with global addresses present in headers of encapsulated > packets. > > 3.3. Global prefixes - global addresses - local addresses > > Internal structures of SAM global prefixes, global addresses, and > local addresses are detailed in Figure 4. > > A branch-interface global prefix necessarily starts with a global > prefix of the zone Z. Its remaining bits are a "branch =20 > identifier" in > the zone (gBkij =3D gZij.zB). > > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > [Page 9] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > |<-------------- Branch global address gB@ -------------=20= > >| > |<-------- Branch global prefix gB --------=20 > > | > |<-- G --><----- Branch identifier iB ----=20 > > | > ________________________________________________________ > | local |branch| Subnet | branch | =20 > branch | > | zone | id | index | Index | =20 > Host | > | Global |Format| (option)| | =20 > endpoint | > | prefix | code | | | =20 > suffix | > | | | | | =20 > (10...00) | > | G | F | S | I | =20 > H | > |_________|______|_________|________________|=20 > ____________| > _______/ <-- s ---><----- i ------> > / ^ ^ > v | | > Specifies s and b / \ > (option) | \ > Specify F <-----.-----|--------------------. \ > \ | \ | > \ v \ v > <-- s ---> <----- i ------=20= > >| > ________________________________________________________ > |local-address| Subnet | next field | =20 > branch | > | constant | index | Delimiter | =20 > index | > | Prefix | | (00...01) =20 > | | > | | | =20 > | | > | P | S | D | =20 > I | > |_____________|_________|_______________|=20 > ________________| > |<-- subnet prefix zS --> > |<-------------- Branch local address B ----------------=20= > >| > > > SAM GLOBAL PREFIXES - GLOBAL ADDRESSES - LOCAL ADDRESSES > > Figure 4 > > Principles that influence the internal structure of branch > identifiers proposed for SAM are the following: > > 1. To permit a flexible hierarchy of local zones, branch =20 > identifiers > should be kept rather short. They should, at least to some > extent, be proportionate to the maximum number of branches > supported in their zone. > > 2. Several subnets must be possible in the zone. For this, a =20 > branch > identifier contain an optional "subnet index" (S), followed the > "branch index" (I) which identifies the branch in its subnet. > (The word "index" is chosen to express that these fields have =20= > no > further internal structure.) > > > > Despres Expires May 5, 2009 [Page =20= > 10] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > 3. For the efficiency of routing tables, intra-zone subnet indexes > have to be in the upper part of local addresses, just behind =20= > the > "constant prefix" (P) that is common to all local addresses. =20= > (In > IPv6, this constant prefix can typically be an ULA prefix of > [RFC4193]; in IPv4 is typically a private-address prefix of > [RFC1918].) > > 4. For efficiency of the neighbor discovery protocol of [RFC2461], > branch indexes B have on the contrary to be in the lowest =20 > part of > branch local addresses B. > > 5. Consequently, it must be possible to extract separately, from a > intra-zone branch identifier iB, the subnet index S and the > interface index I, and for this to know their lengths (s and =20= > i). > > 6. In order to permit to configure several subnet-index lengths, > and/or several interface index lengths, in SAM zones, an =20 > optional > branch-identifier "format code" (F) is placed at the =20 > beginning of > branch identifiers B (just before the optional subnet index S, > and the branch index B). Each format codes specifies a subnet- > index length s and an interface-index length i. Format codes T > may have different lengths, but must be non overlapping =20 > prefixes > to be recognized. > > Since the local address B of a branch interface starts with a > constant prefix P followed by the interface subnet index S , and is > terminated by the interface-index of the interface, space is left > between them. It is filled with a next-field delimiter (D). Its > format, a series of 0s followed by a 1, i.e. 00...01 with a minimal > length of 1 bit, is chosen so that knowing the constant prefix P =20= > and > the subnet prefix of a branch interface, lengths s and i of the its > subnet index S and of its interface index I can be determined. =20 > Then, > the identifier format F to be placed in global prefixes of B can be > derived from these lengths s and i. > > 3.4. Endpoint global address to branch local address mapping > > Detailed steps by which a branch local address B is derived from =20= > from > the global address of a branch-side endpoint are presented in > Figure 5. > > > > > > > > > > > > Despres Expires May 5, 2009 [Page =20= > 11] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > ________________________________________________________ > | Endpoint Global =20 > address | > | =20 > gE | > |=20 > ________________________________________________________| > (A) ANALYSIS || > \/ > ___________________________________________ ............ > | Global | id | Subnet | branch | =20 > endpoint : > | prefix |Format| index | Index | =20 > suffix : > | G | F | S | I | =20 > E : > |_________|______|_________|=20 > ________________|............: > | | | | > 1. Match found | | | | > in the G list ___| | | | > | | | > 2. Match found | | | > in the F list ______| | | > | | > 3. length defined by F _______| | > . | > 4. length defined by F ____________________| > . . > (B) CONSTRUCTION . || . > . \/ . > 5. The current . . > local-address prefix __ . . > | . . > 6. =46rom step 3. _______:______.__ . > | | . > 7. =46rom step 4. _______:_________:_________.__________ > | | | > 8. Binary 00...01 _____:_________:________ | > | | | | > ______________|_________|________|___________|__________ > | local-address | Subnet |next field | =20 > branch | > | Prefix | index | Delimiter | =20 > Index | > | P | S | D | =20 > I | > |_________________|_________|___________|=20 > ________________| > |<--------------- Branch Local address B ---------------=20= > >| > > DERIVING A BRANCH LOCAL ADDRESS FROM AN ENDPOINT GLOBAL =20 > ADDRESS > > Figure 5 > > > > > > > > > Despres Expires May 5, 2009 [Page =20= > 12] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > 3.5. Privacy protection > > In a zone where privacy protection is desired, the privacy option =20= > can > be turned on. Principles of this option are the following: > > o Fields that identify branch-side IP endpoints in privacy =20 > protected > zones, or transport endpoints if endpoints are at this layer, =20= > are > obfuscated in e2e packets that traverse the the global Internet. > > o This obfuscation is stateless and reversible. > > o Branch SAMs of a privacy-protected zone are informed of =20 > parameters > of this obfuscation. They can thus know which "hidden" =20 > addresses > (or addresses plus ports), appear on the global Internet in =20 > place > of their "clear" addresses (or address plus ports). These clear > addresses are those from which local addresses are derived in =20= > the > privacy-protected zone and in zones that are lower in the > hierarchy. > > o In these lower zones, all branch SAMs are informed that a root =20= > SAM > in the global-Internet direction has activated a privacy option, > and are informed of parameters of this option. They can thus > derive a clear address (or address plus port) from an obfuscated > address (or address plus port), and conversely. They can also > avoid to activate the privacy so that obfuscation is never done > more than once. > > Parameters of a privacy option are a privacy global prefix (PPm) =20= > and > a scrambling multiplier (PMm). The prefix is that which, at the > beginning of global addresses, is not obfuscated in the global > Internet. The multiplier is a 64 bit odd constant. > > Obfuscation consists in a modulo 2^n multiplication by the =20 > scrambling > multiplier, where n is the number of bits to be obfuscated. De- > obfuscation is the modulo 2^n multiplication by the inverse of the > scrambling multiplier (for odd numbers, such an inverse modulo 2^n > always exists). > > In hosts in which the branch SAM is informed of an active privacy > option, applications that ask for their address and their port at > their socket interface, get them in hidden form, that which appears > in the global Internet. The e2e principle is thus preserved =20 > despite > the fact that the topology of the privacy-protected zone and that =20= > of > lower zones in the hierarchy are all hidden, and despite the fact > that successive transport connections from a same host cannot, in =20= > the > global Internet, be related to a single host. > > Ports that are concerned with the privacy option are only the IANA > > > > Despres Expires May 5, 2009 [Page =20= > 13] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > defined dynamic and/or private ports (ports 49152 to 65535, those > starting with binary 11). Well known ports and registered ports, > which have an e2e meaning not to be lost must not be obfuscated. > > Since some applications, e.g. active mode FTP of [RFC0959], work on > port pairs rather than on individual ports, port bits to be > obfuscated must exclude the las one. Port bits that are part of > obfuscated endpoint identifiers are then bits 2 to 14. > > > > gY > ^ > | > ... > e2e packet: gZ11.F2.hhhh->gY [TCP hh->80 [data]] > ^ > | > gZkij ROOT ZONE R > ___________________________:________________________ > |(Z) .--> (root =20 > SAM) | > Privacy-option ON / =20 > Rk | > for prefix PP1 =3D gZkij.F1 ---' ^ LOCAL ZONE =20= > Z | > with multiplier PM1 =20 > | | > | =20 > | | > =20 > | ... | > encapsulated | [ B->R [ gZkij.cccc->gY [TCP cc->80 =20 > [data]] | > packet =20 > | | > | =20 > ^ | > | =20 > | | > | =20 > B | > |=20 > ___________________________:________________________| > (branch SAM) > Clear-address packet: gZkij.F1.cccc->gY [TCP cc->80 [data]] > e2e packet: gZkij.F1.hhhh->gY [TCP hh->80 [data]] > where tmp =3D modulo 2^m (PM1 x (cccc . (bits 2 to 14 of cc)) > where m =3D length of cccc + length of cc - 3 > hhhh =3D bits 0 to (length of hhhh - 1) of tmp > hh =3D cc in which bits 2-15 are replaced by > bits(length of PP1 TO m - 1) of tmp . > > SAM PRIVACY OPTION ILLUSTRATION > > Figure 6 > > Figure 6 illustrates the effect of the privacy option. The =20 > option is > supposed to be on, in the root SAM of the zone, for its global =20 > prefix > gZkij and its identifier format F1. The privacy-option prefix is > > > > Despres Expires May 5, 2009 [Page =20= > 14] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > therefore PP1 =3D gZ11.F2. the scrambling multiplie ris PM1. > > 3.6. SAM parameters > > Table 3 to Table 5 of this section present the complete set of SAM > parameters described in previous sections. > > +-----------------------+-----+ > | constant local Prefix | TTL | > +-----------------------+-----+ > | ... | ... | > | Pm | PTm | > | ... | ... | > +-----------------------+-----+ > > CONSTANT PREFIX PARAMETERS > > Table 1 > > +--------------------+-----+------------------=20 > +---------------------+ > | identifier Format | TTL | Subnet-index | Interface-=20 > index | > | code | | Length | =20 > Length | > +--------------------+-----+------------------=20 > +---------------------+ > | ... | ... | ... =20 > | ... | > | Fn | FTn | SLn | =20 > ILn | > | ... | ... | ... =20 > | ... | > +--------------------+-----+------------------=20 > +---------------------+ > > IDENTIFIER-FORMAT PARAMETERS > > Table 2 > > +-----------------+-----+---------------+-----+---------------=20 > +-----+ > | Root local | TTL | Global Prefix | ... | Global Prefix =20 > | ... | > | address | | 1 | | j =20 > | | > +-----------------+-----+---------------+-----+---------------=20 > +-----+ > | ... | ... | ... | ... | ... =20 > | ... | > | Ri | RTi | gZi1 | ... | gZij =20 > | ... | > | ... | ... | ... | ... | ... =20 > | ... | > +-----------------+-----+---------------+-----+---------------=20 > +-----+ > > ROOT PARAMETERS > > Table 3 > > > > > > > > Despres Expires May 5, 2009 [Page =20= > 15] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > +--------------------+------+ > | Global zone prefix | TTL | > +--------------------+------+ > | ... | ... | > | gZij | GTij | > | ... | ... | > +--------------------+------+ > > GLOBAL-PREFIX PARAMETERS > > Table 4 > > +-----------------------+-----+---------------------------+ > | Privacy-option Prefix | TTL | Privacy-option Multiplier | > +-----------------------+-----+---------------------------+ > | ... | ... | ... | > | PPp | PTp | PMp | > | ... | ... | ... | > +-----------------------+-----+---------------------------+ > > PRIVACY-OPTION PARAMETERS > > Table 5 > > 3.7. Port-range-based extended IPv4 addressing > > For a dual stack host not to break the e2e principle when it > establishes a connection with an remote endpoint that is still only > reachable in IPv4, it must have a global IPv4 address. Because of > the IPv4 address shortage, this address may however be shared with > other hosts. For this, SAM accepts "port-extended" IPv4 prefixes, > longer than 32 bits. Bits beyond the first 32 define a port =20 > range in > the set of dynamic and/or private ports (those in which the two =20 > high > order bits are binary 11). For example, a 3-bit prefix extension =20= > 010 > imposes that branch-side hosts use only ports starting with binary > 11010. > > Note that, due to the systematic encapsulation of global packets in > local packets of SAM, routing within SAM zones is not concerned =20 > with > theses "port-extended" IPv4 addresses. Only root SAMs and branch > SAMs have to know about of port ranges. > > The branch SAM in a host that is assigned a port-restricted IPv4 > address has to inform its socket interface of the port range > available to applications, and to inform its internal NAT if it has > one. Consequences for applications, and for NATs, of restricted =20= > port > ranges, are out of the scope of this SAM specification. Other > documents are available on the subject, e.g. [Boucadair], which > > > > Despres Expires May 5, 2009 [Page =20= > 16] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > however requires further study. > > > 4. SAM Application examples > > 4.1. Address independence in an IPv6 site > > In the example of Figure 7, we consider a home or SOHO site in =20 > which > an Ethernet and/or WiFi LAN is deployed. Its global IPv6 prefix gZ > is 2001:0db8:9999::/48. > > Local addressing is done in an IPv6 private space. To keep address > shorts in the figure, the constant prefix of these addresses is > fc00/8, the shortest prefix reserved for private IPv6 addressing in > [RFC4193]. (This prefix could however be replaced by a full fdxx: > xxxx:xxxx::/48 prefix, as recommended in [RFC4193] for ULAs, =20 > without > changing the substance of the example.) > > The site is configured to support 255 branch interfaces on the LAN > (each branch being indifferently a host and/or a router). To > facilitate future changes, a branch-identifier format code F1, =20 > set to > 0/4, is used in branch global prefixes. > > SAM parameters of the site are then following (ignoring TTLs): > > Constant local prefix: P1 =3D fc00/8 > > Identifier format code: F1 =3D 0::/4 > > Subnet index length: SL1 =3D 0 (non applicable) > > Interface index length: IL1 =3D 8 > > Root local address: R1 =3D fc00::0101 > > Zone Global prefix: gZ11 =3D 2001:0db8:9999::/48 > > Privacy option prefix: none in this example > > We now consider a SAM-capable PC which serves as a router for a > bluetooth link. On this link, a bluetooth mobile phone is active. > (Configuring a root-SAM in the PC would permit the mobile phone, if > acting as a SAM-capable router, to assign global prefixes and > addresses, to hosts behind it. But this would have been too much =20= > for > the example). > > > > > > > Despres Expires May 5, 2009 [Page =20= > 17] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > | > | > 2001:0db8:9999::/48 > _________________:_________________ > |(Z) (root SAM) for 2^8 hosts | > Site | fc00::0101 | > gateway | | > | | > | fc00::0155 | > |_________________:_________________| > | > Ethernet and/or WiFi ... > fcOO::/64 | > > fc00::0155 > (branch SAM) > =3D> + 2001:0db8:9999:0550::/60 > __________:__________ > |2001:0db8:9999:0558::| > PC | | > |_____________________| > /___________._________/ > | > Bluetooth ... > 2001:0db8:9999:0550::/64 | > | > 2001:0db8:9999:0550:< eui64 IID > > | > |_|__ > | | > Mobile phone | | > | | > |_____| > > Figure 7 > > The PC local address B is fc00::0155, i.e. P.D.I where P is > fc00::/8, where the 8 bits of I are supposed to be 55::/8, and =20 > where > D is binary 00...01 with consequently (128 - 8 -8) =3D 112 bits. > > The PC global prefix gB is therefore 2001:0db8:9999:0550::/60, i.e. > G.F.I, where G is 2001:0db8:9999::/48, where F is 0::/4, and =20 > where I > is 55::/8. > > The PC global address is therefore 2001:0db8:9999:0558::, i.e. gB.E > where E is binary 10...00 with (128 - 48 - 4 - 8) =3D 68 bits. > > The bluetooth link is supposed to have 0::/4 as subnet ID in the =20= > PC. > > > > Despres Expires May 5, 2009 [Page =20= > 18] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > Its /64 subnet prefix is therefore 2001:0db8:9999:0550::/64. > > This simple example illustrates how the SAM logic permits to > establish a hierarchy of routing zones where each host can become a > router, and where the e2e principle is preserved. > > 4.2. Multihoming and extended IPv4 addressing in a home site > > In the example of Figure 8, we consider a home site S, multihomed > with two ISPs A and B. > > ISP A assigns to the site IPv6 prefix 2001:1111:1111:1110::/60, and > IPv4 address 192.0.2.1. > > ISP B can only assign port-restricted IPv4 addresses to its sites > because it has to support up to 2^16 sites, and has only for this =20= > an > IPv4 /18 prefix (namely 198.16.0.0/18, i.e. v4|c610:0000:/18), and > since 18 + 16 =3D 34 which exceeds 32. Having 2001:0db8::/32 as = its > IPv6 prefix, it assigns /48s to its customer sites, in particular > 2001:0db8:0202::/48 to site S. > > Half of its IPv4 address space, namely v4|c608:c000/19 is allocated > to a NAT to support sites that are not SAM capable. The other =20 > half, > i.e. v4|c610:2000/19, is allocated to a root SAM, the local address > of which is supposed to be 2001:0db8::1. > > SAM parameters of the zone of ISP B are then the following: > > Constant local prefix: P1 =3D 2001:0db8: =3D v4|a000::/8 > > Identifier format code: F1 =3D ::/0 (non applicable) > > Subnet index length: SL1 =3D 0 (non applicable) > > Interface index length: IL1 =3D 16 > > Root local address: R1 =3D 2001:0db8::1:1 > > Zone Global prefix: gZ11 =3D v4|c608:8000/19 (=3D198.8.128.0/19). > > Privacy option prefix: none in this example (::/0) > > > > > > > > > > > Despres Expires May 5, 2009 [Page =20= > 19] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > 198.16.0.0/18 > 2001:0db8::/32 =3Dv4|c610:0000:/18= > ____|__________________|____________ > |(B) / =20 > \ | > | | v4|=20 > c610:2000/19 | > | v4|c608:c000/19 =20 > | | > | (NAT) (root =20 > SAM) | > | 0.0.0.0/0 =20 > 2001:0db8::1 | > |(A) | =20 > | | > | | =20 > | | > |2001:1111:1111:1110::/60| | (2^16 SAM =20 > sites) | > | 192.0.2.1 | =20 > | | > | =3Dv4|c000:0201/32 | | =20 > 2001:0db8:0202::/48 | > |________________:_______| |=20 > ___________________:________________| > | (branch SAM) > | =3D> + v4|c610:2040:4000::/35 > | =3D 198.8.128.64/ports 11010... > ________________:______________________________:________________ > |(S) / \ / =20 > \ | > | | v4|c000:0201:0000::/33 | v4|=20 > c610:2040:4000::/36| > | | ::/0 | ::/=20 > 0 | > | v4|c600:0201:8000::/33 | v4|c608:2040:6000::/36 =20 > | | > | (NAT) (root SAM) (NAT) (root =20 > SAM) | > | 0.0.0.0/0 fc00::0011 0.0.0.0/0 =20 > fc00::0012 | > =20 > | | > | (2^4 SAM =20 > hosts) | > | =20 > fc00::0018 | > |=20 > _____________________________:__________________________________| > | > HOST (H) (branch SAM) > =3D> + 2001:1111:1111:1118:8000::0008/64 > + 2001:0db8:0220:4800::0008/52 > + v4|c000:0201:4000::/37 =3D 192.0.2.1 ports 1101000... > + v4|c610:2040:5000::/40 =3D 198.16.32.64 ports = 1101001000... > : > HOST > > PRIVATE-ADDRESSING- AND DUAL-HOMING- SITE WITH E2E CAPABILITY > > Figure 8 > > In site S, the branch SAM of its root interface with ISP B derives > from its IPv6 prefix 2001:0db8:O2O2::/48, and from SAM parameters =20= > of > ISP B, its IPv4 prefix v4|c610:2040:4000::/35, which is a port- > restricted one. > > Two root SAMs are configured in site S. Its local-address constant > prefix is fc00::/8 as. Half of the each available IPv4 addressing > > > > Despres Expires May 5, 2009 [Page =20= > 20] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > space is reserved for a NAT, and the other half for a root SAM. > > Parameters of SAMs of site S are then the following: > > Constant local prefix: P1 =3D fc00/8 > > Identifier format code: F1 =3D 0::/4 > > Subnet index length: SL1 =3D 0 > > Interface index length: IL1 =3D 8 > > Root local addresses: R1 =3D fc00::0011; R2 =3D fc00::0012 > > Zone Global prefixes: gZ11 =3D 2001:1111:1111:1110::/60; gZ12 =3D = =20 > v4| > c000:0201/32; gz21 =3D 2001:0db8:0202::/48; gZ22 =3D v4| > c610:2040:4000::/35 > > Privacy option prefix: none in this example (::/0) > > Among the 16 hosts of home site S, Host H is supposed to have local > address fc00::0018. As shown on the figure, the branch SAM of =20 > host H > then derives from this local address two IPv6 global prefixes, two > IPv6 global host addresses starting with these prefixes, and two > port-restricted IPv4 prefixes. With these prefixes, it can use, > without breaking the e2e principle, 512 ports for connections via =20= > ISP > A, and 64 ports via ISP B. > > > 5. SAM as an alternative to NATs in IPv6 > > With SAM as specified, all NAT44 services that have been listed in > Section 2 can be offered in IPv6 without stateful processing and > without breaking the e2e principle: > > 1. In a private-addressing IPv6 site, hosts can know their global > addresses to use them in e2e packets that are encapsulated in > local packets to traverse the site. Renumbering is then > automated simply by automating advertisement of SAM parameter > changes (in DHCP and/or with router advertisements). > > 2. The fact that NAT44s are in general configured with by default > rejection of all incoming calls can have a simple stateless > equivalent in IPv6: > > * By default, reject all incoming packets that have a branch- > side port in the well known or in the IANA defined =20 > registered > port ranges. > > > > Despres Expires May 5, 2009 [Page =20= > 21] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > * By default, reject all TCP incoming packets that are =20 > attempts > to open new incoming connections (SYN packets without ACK). > > 3. In a SAM-capable site, SAM-capable hosts can take advantage of > site multihoming with full compatibility with ingress filtering > of [RFC3704] in both the site itself and in ISP networks to =20 > which > it is connected. > > 4. The privacy protection described in Section 3.5 maintains the =20= > e2e > principle. It is expected to be largely sufficient in =20 > practice. > (Sophisticated hackers would probably find ways around it, and > identify who does what in sites havin the privacy-protection > option, but NAT44s are not perfect for privacy protection > either). > > 5. As we have seen, SAM global addresses contain a flexible > succession of branch identifiers, so that it becomes possible =20= > to > set up a flexible hierarchy of private addressing zones. In > particular, host-rooted subnets become possible without =20 > breaking > the e2e principle. > > For information, no intellectual property right has been applied =20= > for > by the author on any of SAM mechanisms. The intent is to =20 > facilitate > IPv6 deployment with new mechanisms that still enhance its =20 > potential. > > > 6. Security considerations > > Like any function where some parameters have to be configured, SAM > introduces a risk of human errors. > > Besides that, no security risk introduced by SAM has so far been > identified. In particular: > > Provided consistency between local addresses present in =20 > encapsulating > packets and global addresses present in encapsulated packets are > systematic, no more address spoofing is possible than without SAM. > > Due to the stateless operation of SAM, its scalability is high. > Prevention against denial of service attacks should therefore =20 > remain > easy even for very intense traffic (e.g. using load balancers in > front of parallel devices). > > > 7. IANA Considerations > > If and when this specification is stabilized and approved, option > codes in DHCP, DHCPv6, and ND will have to be defined to > > > > Despres Expires May 5, 2009 [Page =20= > 22] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > automatically convey SAM parameters to branch SAMs. > > > 8. Acknowledgements > > As this specification has evolved during many months, precious > encouragement and remarks were received from Mark Townsley. He has > to be warmly thanked for it. Concerning what SAM can bring to =20 > port- > restricted IPv4 addresses, stimulating discussions with Dan Wing, > Teemu Savolainen, Gabor Bajko, Pierre Levis, Jean-Luc Grimault, and > Alain Villefranque, have influenced progress of the work. =20 > Gratitude > is due to them for this. Challenging remarks, and a few (deserved) > criticisms from Alain Durand have also helped to better analyze how > SAM will coexist with NATs. He deserves credit for it. > > > 9. References > > 9.1. Normative References > > [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., =20= > and > E. Lear, "Address Allocation for Private Internets", > BCP 5, RFC 1918, February 1996. > > [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", > RFC 2131, March 1997. > > [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., > and M. Carney, "Dynamic Host Configuration Protocol for > IPv6 (DHCPv6)", RFC 3315, July 2003. > > [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast > Addresses", RFC 4193, October 2005. > > [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, > "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, > September 2007. > > 9.2. Informative References > > [6rd] Despres, R., "IPv6 Rapid Deployment on IPv4 > infrastructures (6rd) - Work in progress > (draft-despres-6rd-02)", October 2008. > > [Boucadair] > Boucadair, M., Grimault, J-L., Levis, P., and A. > Villefranque, "Behaviour of BitTorrent service in an IP > Shared Address Environment > > > > Despres Expires May 5, 2009 [Page =20= > 23] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > (draft-boucadair-behave-bittorrent-portrange-02 - work =20= > in > progress)", january 2009. > > [LISP] Farinaci, D., Fuller, V., Oran, D., Meyer, D., and S. > Brim, "Locator/ID Separation Protocol (LISP) - > draft-farinacci-lisp-09", December 2008. > > [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", > STD 9, RFC 959, October 1985. > > [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor > Discovery for IP Version 6 (IPv6)", RFC 2461, > December 1998. > > [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address > Translator (NAT) Terminology and Considerations", > RFC 2663, August 1999. > > [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains > via IPv4 Clouds", RFC 3056, February 2001. > > [RFC3286] Ong, L. and J. Yoakum, "An Introduction to the Stream > Control Transmission Protocol (SCTP)", RFC 3286, May =20 > 2002. > > [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- > Multihoming Architectures", RFC 3582, August 2003. > > [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for =20 > Multihomed > Networks", BCP 84, RFC 3704, March 2004. > > [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) =20 > Developers > Should Think About", RFC 4219, October 2005. > > [RFC4301] Kent, S. and K. Seo, "Security Architecture for the > Internet Protocol", RFC 4301, December 2005. > > [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., =20= > and > E. Klein, "Local Network Protection for IPv6", RFC 4864, > May 2007. > > [RFC4960] Stewart, R., "Stream Control Transmission Protocol", > RFC 4960, September 2007. > > [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site > Automatic Tunnel Addressing Protocol (ISATAP)", RFC =20 > 5214, > March 2008. > > [Shim6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming > > > > Despres Expires May 5, 2009 [Page =20= > 24] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > Shim Protocol for IPv6 - Work in progress > (draft-ietf-shim6-failure-detection-09)", October 2007. > > [draft-carpenter-renum-needs-work-01] > Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering > still needs work - Work in progress", December 2008. > > [shim6 fail detec] > Arkko, J. and I. van Beijnum, "Failure Detection and > Locator Pair Exploration Protocol for IPv6 Multihoming - > Work in progress (draft-ietf-shim6-failure-=20 > detection-09)", > July 2007. > > > Author's Address > > Remi Despres > 3 rue du President Wilson > Levallois, > France > > Email: remi.despres@free.fr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 [Page =20= > 25] > > > Internet-Draft Stateless Address Mapping (SAM) November =20= > 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided =20 > on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =20 > REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST =20= > AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, =20 > EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE =20 > USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be =20 > claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. =20 > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the =20 > use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR =20 > repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Despres Expires May 5, 2009 [Page =20= > 26] > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Mon Mar 16 18: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 863F93A6804; Mon, 16 Mar 2009 18:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.925 X-Spam-Level: X-Spam-Status: No, score=-4.925 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, J_CHICKENPOX_22=0.6, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, 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 IFmd-CNgdCK7; Mon, 16 Mar 2009 18:51:34 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 94B673A6452; Mon, 16 Mar 2009 18:51:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,375,1233532800"; d="scan'208";a="156736965" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 17 Mar 2009 01:52:16 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2H1qGxE015253; Mon, 16 Mar 2009 18:52:16 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2H1qExb005885; Tue, 17 Mar 2009 01:52:14 GMT From: "Dan Wing" To: "'Margaret Wasserman'" , "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" References: <49BA2DD6.8080001@free.fr> <96B651AC-8244-44DF-8937-2FB79C119B49@lilacglade.org> Date: Mon, 16 Mar 2009 18:52:14 -0700 Message-ID: <001101c9a6a2$ff0acb20$c2f0200a@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 Thread-Index: AcmmlT9aq9s0NxBOSZ+iCQq2e8QfywADS/oQ In-Reply-To: <96B651AC-8244-44DF-8937-2FB79C119B49@lilacglade.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=74561; t=1237254736; x=1238118736; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20FYI=3A=20draft-despres-sam-0 2=20=20enclosed |Sender:=20; bh=pfaaVsWar6nrhYNKeJHo0K+aMbCVNH24+NAx+pUYV8A=; b=gpCg+cL6Srg4Gh5PNSSBop0c50HHaBRVCt8ht4ZyhJQ0BaLm6vCYCq2vik YTQM8ilOvdIfCMmfN0aP1Q/1nq72CVMysm7SSmT+gvYbcNhHQxZpSInQ5Xm7 kpKg6BZNmF; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Softwires WG' , 'Internet Area' , 'Behave WG' , nat66@ietf.org Subject: Re: [BEHAVE] FYI: draft-despres-sam-02 enclosed X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: nat66@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 01:51:47 -0000 > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of Margaret Wasserman > Sent: Monday, March 16, 2009 5:13 PM > To: R=E9mi Despr=E9s > Cc: Softwires WG; Behave WG; Internet Area > Subject: Re: [BEHAVE] FYI: draft-despres-sam-02 enclosed >=20 >=20 > Hi Remi, >=20 > I have a few high-level comments/questions on this draft from=20 > my first =20 > reading, and I may have more after I have reviewed it in more detail. >=20 > (1) You have indicated that you would like to discuss this draft in =20 > the 6AI BOF, but you have not cc:ed the mailing list for the=20 > 6AI BOF (nat66@ietf.org=20 > ).=20 He did, in another email that went to both NAT66 and SHARA, http://www.ietf.org/mail-archive/web/nat66/current/msg00106.html but my = email filters put that message into my SHARA folder. I added nat66@ietf.org to the CC list in the hopes that discussion = regarding sam-02's applicability to solve 6AI will move to nat66 mailing list. = Reply-to is also set to nat66. > Also, have you talked to the chairs of the 6AI BOF (Bob=20 > Hinden and =20 > Dan Wing) about whether they are willing to include this=20 > draft on the =20 > agenda, despite the fact that it has not been posted to the I-D =20 > archive?=20 He has requested agenda time. We are still considering it and discussion of sam-02 on the nat66 mailing list would be useful=20 to reach a decision. > There doesn't appear to be an agenda online for the=20 > 6AI BOF =20 > yet, so I am not sure if it will be included. Yes, we are still trying to sort through some plans. Sorry we don't have a draft agenda posted yet. -d > (2) The end hosts in the SAM system need to know their globally =20 > routable addresses, so how can SAM be said to provide address =20 > independence? >=20 > (3) Exactly what formulation of the end-to-end principle are you =20 > referring to in this paper when you indicate that SAM=20 > preserves it in =20 > IPv6? >=20 > My understanding of the end-to-end principle is that it has=20 > to do with =20 > putting intelligence at the edges of the network (in hosts=20 > vs. routers/=20 > middleboxes) and with putting certain function at the top of the =20 > protocol stack (apps layer vs. lower layers). This is based on my =20 > understanding (and recollection) of a paper by Jerry Saltzer,=20 > D. Reed =20 > and Dave Clark written in the mid 1980s, which you can find here: >=20 > http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt >=20 > It is also reasonably well-summarized in this Wikipedia article. >=20 > http://en.wikipedia.org/wiki/End-to-end_principle >=20 > Based on my understanding of the end-to-end principle, I=20 > don't see any =20 > significant difference in SAM vs. NAT66 WRT how much they=20 > maintain (or =20 > violate) the end-to-end principle, as both mechanisms place some =20 > functions/intelligence in the infrastructure. > > Margaret >=20 >=20 >=20 > On Mar 13, 2009, at 5:56 AM, R=E9mi Despr=E9s wrote: >=20 > > Hi, > > For your information, draft-despres-sam-02, which was ready=20 > too late =20 > > to be posted before IETF 74, is enclosed below > > > > It is a major update of the version-01 which was presented=20 > at IETF 73: > > - In Softwires, ref.: > >=20 > http://www.ietf.org/proceedings/08nov/slides/softwire-3/softwi > re-3_files/slide0002.htm > > - In Behave, ref.: > > http://www.ietf.org/proceedings/08nov/slides/behave-15.pdf > > > > In San Francisco, its part that deals with NAT66 avoidance=20 > is to be =20 > > discussed at the 6IA BOF meeting (ex NAT66). > > Its part that deals with Port-Range extension, is to be=20 > discussed at =20 > > the SHARA BOF. > > > > Comments most welcome. > > > > Regards, > > > > RD > > > > > > > > > > > > > > Internet Engineering Task Force R. =20 > > Despres > > Internet-Draft =20 > November =20 > > 2008 > > Intended status: Standards Track > > Expires: May 5, 2009 > > > > > > Stateless Address Mapping (SAM) > > Avoiding NATs and restoring the end-to-end principle in IPv6 > > draft-despres-sam-02 > > > > Status of this Memo > > > > By submitting this Internet-Draft, each author=20 > represents that any > > applicable patent or other IPR claims of which he or she is aware > > have been or will be disclosed, and any of which he or=20 > she becomes > > aware will be disclosed, in accordance with Section 6 of 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 =20 > > months > > and may be updated, replaced, or obsoleted by other=20 > documents at =20 > > 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 May 5, 2009. > > > > Abstract > > > > Stateless Address Mapping (SAM) is a generic mechanism to support > > global addressing across network zones where routing is=20 > based on a > > different address space. With it, the end-to-end=20 > principle, lost =20 > > in > > IPv4 with the deployment of NATs, can be restored without losing > > services that NAT44s offer beyond address-space=20 > extension (private > > addressing, basic firewall, site multihoming, privacy protection, > > host-rooted subnets). Global-address packets are encapsulated in > > local-address packets to traverse SAM zones, and global=20 > prefixes =20 > > are > > statelessly mapped into local addresses. For the IPv6-IPv4 > > coexistence period, port-restricted IPv4 addresses are used to =20 > > extend > > the global IPv4 address space. > > > > > > > > Despres Expires May 5, 2009 =20 > > [Page 1] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > Table of Contents > > > > 1. Introduction and general problem =20 > > statement . . . . . . . . . . 3 > > 2. NAT44 services availability of which in IPv6 is =20 > > desirable . . 4 > > 2.1. Private addressing (easy =20 > > renumbering) . . . . . . . . . . 4 > > 2.2. Basic firewall (by default, no incoming =20 > > connections) . . . 4 > > 2.3. Site multihoming (automatic =20 > > fallback) . . . . . . . . . . 4 > > 2.4. Privacy =20 > > protection . . . . . . . . . . . . . . . . . . . . 4 > > 2.5. Host-rooted =20 > > subnets . . . . . . . . . . . . . . . . . . . 5 > > 3. SAM =20 > > specification . . . . . . . . . . . . . . . . . . . . . . 5 > > 3.1. Local Zones - Root SAMs - Branch =20 > > SAMs . . . . . . . . . . 5 > > 3.2. Encapsulation of global packets in local =20 > > packets . . . . . 7 > > 3.3. Global prefixes - global addresses - local =20 > > addresses . . . 9 > > 3.4. Endpoint global address to branch local address =20 > > mapping . 11 > > 3.5. Privacy =20 > > protection . . . . . . . . . . . . . . . . . . . . 13 > > 3.6. SAM =20 > > parameters . . . . . . . . . . . . . . . . . . . . . . 15 > > 3.7. Port-range-based extended IPv4 =20 > > addressing . . . . . . . . 16 > > 4. SAM Application =20 > > examples . . . . . . . . . . . . . . . . . . . 17 > > 4.1. Address independence in an IPv6 =20 > > site . . . . . . . . . . . 17 > > 4.2. Multihoming and extended IPv4 addressing in a home =20 > > site . 19 > > 5. SAM as an alternative to NATs in =20 > > IPv6 . . . . . . . . . . . . 21 > > 6. Security =20 > > considerations . . . . . . . . . . . . . . . . . . . 22 > > 7. IANA =20 > > Considerations . . . . . . . . . . . . . . . . . . . . . 22 > > 8. =20 > > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 > > 9. =20 > > References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 > > 9.1. Normative =20 > > References . . . . . . . . . . . . . . . . . . . 23 > > 9.2. Informative =20 > > References . . . . . . . . . . . . . . . . . . 23 > > Author's =20 > > Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 > > Intellectual Property and Copyright =20 > > Statements . . . . . . . . . . 26 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > > [Page 2] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > 1. Introduction and general problem statement > > > > In IPv4, Network Address Translations have been extensively =20 > > deployed > > (NAT44s). They are key to mitigate the IPv4 address=20 > shortage. But > > they also offer various auxiliary services, described in=20 > Section 2: > > private addressing, basic firewall, site multihoming, privacy > > protection, host-rooted subnets. > > > > In counterpart to these auxiliary services, these NAT44s have > > introduced two drawbacks: > > > > o Non compliance with the end-to-end principle of the Internet > > (e2e). > > > > Negative consequences include incompatibility with=20 > the IPsec > > security mechanism, and difficulties for hosts to=20 > know their > > own global addresses, which they need for connection > > redirections, for host referrals, and and, in sites having > > several site entrance routers, for multihoming support > > mechanisms like the SCTP of [RFC4960] and [Shim6]. > > > > o Stateful operation. > > > > Most NAT44s are in fact stateful NAPTs (ref. < xref > > target=3D"RFC2663" />): to support more local=20 > addresses than =20 > > they > > have external addresses, they maintain per-transport-=20 > > connection > > states. Negative consequences include limited=20 > scalability, =20 > > and > > the risk of denial of service attacks that go with it, as =20 > > well > > as single points of failures. > > > > Since no global address shortage is in view in IPv6, the=20 > following > > questions have to be asked: > > > > o Which NAT44 services can, in IPv6, be offered statelessly and > > without breaking the e2e principle? > > > > o How? > > > > This draft proposes to answer these questions more=20 > completely, and > > with more technical details, than [RFC4864], the most advance > > document on the subject so far. > > > > For this, a Stateless Address Mapping generic mechanism is =20 > > introduced > > (SAM). > > > > Conclusion, is that, provided SAM is supported in nodes at =20 > > borders of > > independently administered routing zones, the e2e=20 > principle can be > > restored in IPv6, for all identified useful functions of NAT44s. > > > > > > > > Despres Expires May 5, 2009 =20 > > [Page 3] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > (This conclusion needs however to be confirmed after=20 > further work =20 > > on > > SAM details, after criticisms by other experts, after=20 > some possible > > bug corrections, and after validations with running code.) > > > > Thus, traversal of NATs in ISP infrastructures can be avoided. > > (These NATs do provide useful connectivity to some=20 > non-SAM-capable > > nodes, but have the drawback of breaking the e2e=20 > principle, with =20 > > the > > mentioned consequences on security, referrals, multihoming, > > scalability and reliability. > > > > > > 2. NAT44 services availability of which in IPv6 is desirable > > > > 2.1. Private addressing (easy renumbering) > > > > With NAT44s, when a prefix assigned by an ISPs to a=20 > customer site =20 > > is > > modified, local IP addresses in the site can remain unchanged. > > > > 2.2. Basic firewall (by default, no incoming connections) > > > > Most NAT44s, being NAPTs, and therefore maintaining=20 > states for all > > TCP and UDP connections, have as a byproduct a protection against > > incoming connections (unless some "holes" are "punched" in this > > protection, under explicit customer control). This level of =20 > > security > > protection is largely relied upon. > > > > 2.3. Site multihoming (automatic fallback) > > > > In a site is multi-homed, and if it has a NAT device=20 > supporting all > > its ISP interfaces, its hosts can take advantage of multihoming > > without having to support any multihoming-specific=20 > function. This > > level of multihoming support is better than none. > > > > (For this, a NAT44 needs only to make sure that, for=20 > each transport > > connection, all outgoing packets go through the same=20 > ISP. Thus, if > > an ISP access fails, current TCP and UDP connections=20 > that go via =20 > > this > > ISP are broken, but theycan immediately be replaced by new ones.) > > > > 2.4. Privacy protection > > > > From outside a site where a NAT44 operates in NAPT mode, it is > > difficult to determine which hosts establish which=20 > connections. =20 > > This > > level of privacy protection, in particular for some web=20 > requests, =20 > > is > > an added value. > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > > [Page 4] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > 2.5. Host-rooted subnets > > > > Behind a host that is assigned a single IPv4 address, it is =20 > > possible, > > with a NAT44 in the host, to deploy a private subnet. As modern > > operating systems include a router function with a NAT44, a =20 > > computer > > can can serve as a root for a LAN. > > > > Thus, the distinction between hosts and a routers is no longer a > > distinction between types of devices. It has become only a > > distinction between functions within nodes. > > > > > > 3. SAM specification > > > > 3.1. Local Zones - Root SAMs - Branch SAMs > > > > As presented in Figure 1, the SAM mechanism applies to a=20 > SAM "local > > zone" Z. Routing within this zone is independently=20 > administered, =20 > > and > > is based on a "local address space". > > > > Each SAM zone has one or several "root interfaces" (Ri),=20 > that give > > access to the global Internet. Each one has, in the global =20 > > Internet, > > one or several "global prefixes" (gZij) exclusively assigned to =20 > > zone > > Z. > > > > SAM global prefixes can be global IPv6 and/or global IPv4. SAM =20 > > local > > address spaces can be IPv6 or IPv4, global or private. If both =20 > > IPv4 > > and IPv6 are routed in the zone, one of the two is=20 > chosen for SAM. > > (SAM is in this respect therefore an extension of the 6to4 of > > [RFC3056], of the ISATAP of [RFC5214], and of [6rd], where all =20 > > global > > prefixes are IPv6 and all local address spaces are IPv4). > > > > As explained in Section 3.7, global IPv4 addresses can=20 > be extended > > beyond 32 bits to deal with the IPv4 address shortage during the > > IPv4-IPv6 coexistence period. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > > [Page 5] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > ROOT-SIDE ENDPOINTS > > | /\ | > > | || | > > |_____:_____| || =20 > |______:_____| > > | | > > | ROOT ZONES | > > | gZ22 > > Zone Global prefixes gZij gZ11 gZ21 > > Root interfaces: =20 > > _________:_______________________:________ > > |(Z) (root-SAM) (root-=20 > > SAM) | > > Root local addresses: | R1 =20 > > R2 | > > Ri =20 > > | | > > | SAM ZONE =20 > > Z | > > =20 > > | | > > =20 > > | | > > Branch local addresses: | B1 B2 =20 > > B3 | > > Bk =20 > > | : : : | > > Branch interfaces: |=20 > > ______:________________:_____________:____| > > | | | > > Branch Global prefixes: | (branch-SAM) | > > *gBkij=3DgZij.zBk* =3D> + gB211, gB221, gB222 > > Branch Global Addresses: + gB211@, gB221@, gB222@ > > *gBkij@=3DgBkij.H* || > > BRANCH ZONES || > > \/ > > BRANCH-SIDE ENDPOINTS > > > > ROOT AND BRANCH INTERFACES AND SAMs > > > > Figure 1 > > > > Each root interface that supports a root-SAM function has a local > > address (Rk), and each "branch interface" has a local=20 > address (Bk). > > > > If a "branch SAM" function is supported at a branch interface Bk, > > this interface gets, in addition to its local address, global > > prefixes (gBkij). Each of these prefixes is made of a global =20 > > prefix > > of the zone (gZij) followed by an identifier (zBk) of=20 > the branch in > > its zone. > > > > For each each of its global prefixes gBkij, a branch=20 > interface has > > also a host global address (gBkij@), derived from the prefix by > > appending a standard host suffix (H) to complete the address =20 > > length. > > > > Thus, if a zone D is accessible from the global Internet=20 > via a zone > > hierarchy A, B, C, it has at least gA.aB.bC.cD as a=20 > global prefix =20 > > gD, > > and gA.aB.bC.cD.H as a global address gD@. SAM is thus an > > application of the locator-identifier separation principle. (It > > > > > > > > Despres Expires May 5, 2009 =20 > > [Page 6] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > differs however from [LISP], in that no new protocol is=20 > needed fro > > SAM, just new options in existing protocols such as DHCP=20 > [RFC2131], > > DHCPv6 [RFC3315], or ND [RFC4861], to advertise SAM parameters to > > branch interfaces.) > > > > 3.2. Encapsulation of global packets in local packets > > > > > > endpoint Y Global address: gY > > ^ > > | > > ... > > (3) e2e packet: [ gX->gY [data]] > > ^ > > | > > gZ ROOT ZONE R > > =20 > ______________:______________________ > > |(Z) (root =20 > > SAM) | > > | R =20 > LOCAL ZONE =20 > > Z | > > | =20 > > ^ | > > | =20 > > | | > > =20 > > | ... | > > (2) encapsulated packet: =20 > > | | > > *B =3D la(gX)* | [ B->R [gX-=20 > > >gY[data]] | > > *R =3D parameter* | =20 > > ^ | > > | =20 > > | | > > | =20 > > B | > > |=20 > > ______________:______________________| > > (branch SAM) =20 > BRANCH ZONE B > > =3D> + gB > > ^ > > | > > ... > > (1) e2e packet: [ gX->gY [data]] > > ^ > > | > > endpoint X Global address: gX=3DgZ.id(B).xxx > > > > > > PACKET ENCAPSULATION AND ADDRESS MAPPING - BRANCH SIDE=20 > TO ROOT =20 > > SIDE > > > > Figure 2 > > > > To traverse a SAM local zone, global-address packets are =20 > > encapsulated > > into local address packets, as illustrated in Figure 2=20 > and Figure =20 > > 3). > > > > Thus, compatibility is ensured, within the local zone,=20 > with ingress > > the filtering for multihomed networks of [RFC3704], the=20 > basic anti- > > > > > > > > Despres Expires May 5, 2009 =20 > > [Page 7] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > spoofing mechanism. > > > > > > | > > | ROOT ZONE > > gZ > > =20 > ______________:______________________ > > |(Z) (root-=20 > > SAM) | > > | R =20 > LOCAL ZONE =20 > > Z | > > =20 > > | | > > =20 > > | | > > =20 > > | | > > (2) encapsulated packet: | [ B1->B2 [gE1-=20 > > >gE2[data]] | > > *B1 =3D la(gX)* | --------=20 > > >-------- | > > *B2 =3D la(gY)* | / =20 > > \ | > > | ^ =20 > > | | > > | | =20 > > v | > > | B1 =20 > > B2 | > > |=20 > > ______:_____________________:________| > > BRANCH ZONES: (branch-SAM) (branch-SAM) > > =3D> + gB1 =3D> + = gB2 > > ^ | > > | v > > (3) e2e packet: ... [ E1->E2 =20 > > [data]] > > (1) e2e packet: [ E1->E2 [data]] ... > > ^ | > > | v > > gX=3DgZ.id(B1).xxx =20 > > gY=3DgZ.id(B2).yyy > > _:_ _:_ > > | X | | Y | > > |___| |___| > > > > ADDRESS MAPPING AND PACKET ENCAPSULATION - BRANCH SIDE=20 > TO BRANCH =20 > > SIDE > > > > Figure 3 > > > > For the IP-in-IP encapsulation, the IPv6 next header or the IPv4 > > protocol id which indicates the type of IP payload is set to 41 =20 > > (the > > same value as for 6to4, ISATAP, and 6rd). > > > > Local addresses are determined as follows (illustrated in figures > > Figure 2 and Figure 3): > > > > 1. If an endpoint global address gE, indifferently source or > > destination, is that of a branch-side endpoint, this is > > recognized by the fact that it starts with one of the global > > prefixes of the zone. Then, the local address B is=20 > obtained =20 > > by a > > function B=3Dla(gX), completely determined by SAM=20 > parameters of =20 > > the > > > > > > > > Despres Expires May 5, 2009 =20 > > [Page 8] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > zone (details in Section 3.4). > > > > 2. If an endpoint global address gE, indifferently source or > > destination, is that of a root-side endpoint, this is =20 > > recognized > > by the fact that it doesn't start with any of the global =20 > > prefixes > > of the zone. In this case, the other address gX of=20 > the packet, > > destination or source respectively, is necessarily that of a > > branch-side endpoint (otherwise the packet would not=20 > traverse =20 > > the > > local zone). Then, local address Ri is that of the root > > interface that has, in its assigned global prefixes,=20 > the global > > prefix present at the beginning of the branch-side=20 > address gX. > > > > In multihomed sites, the second of these rules ensures =20 > > compatibility > > with the ingress filtering of [RFC3704] in root zones (if it does > > apply, as necessary for anti-spoofing protection). > > > > In Figure 2 and Figure 3, packets in the reverse direction, not > > shown, would have the same addresses but with sources and > > destinations inverted, and with encapsulations and decapsulations > > made at inverted interfaces. > > > > Decapsulation functions MUST verify, for anti-spoofing=20 > protection, > > that local addresses present in headers of encapsulating=20 > packets =20 > > are > > consistent with global addresses present in headers of=20 > encapsulated > > packets. > > > > 3.3. Global prefixes - global addresses - local addresses > > > > Internal structures of SAM global prefixes, global addresses, and > > local addresses are detailed in Figure 4. > > > > A branch-interface global prefix necessarily starts with a global > > prefix of the zone Z. Its remaining bits are a "branch =20 > > identifier" in > > the zone (gBkij =3D gZij.zB). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > > [Page 9] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > |<-------------- Branch global address gB@=20 > -------------=20 > > >| > > |<-------- Branch global prefix gB --------=20 > > > | > > |<-- G --><----- Branch identifier iB ----=20 > > > | > > =20 > ________________________________________________________ > > | local |branch| Subnet | branch | =20 > > branch | > > | zone | id | index | Index | =20 > > Host | > > | Global |Format| (option)| | =20 > > endpoint | > > | prefix | code | | | =20 > > suffix | > > | | | | | =20 > > (10...00) | > > | G | F | S | I | =20 > > H | > > |_________|______|_________|________________|=20 > > ____________| > > _______/ <-- s ---><----- i ------> > > / ^ ^ > > v | | > > Specifies s and b / \ > > (option) | \ > > Specify F <-----.-----|--------------------. \ > > \ | \ | > > \ v \ v > > <-- s ---> =20 > <----- i ------=20 > > >| > > =20 > ________________________________________________________ > > |local-address| Subnet | next field | =20 > > branch | > > | constant | index | Delimiter | =20 > > index | > > | Prefix | | (00...01) =20 > > | | > > | | | =20 > > | | > > | P | S | D | =20 > > I | > > |_____________|_________|_______________|=20 > > ________________| > > |<-- subnet prefix zS --> > > |<-------------- Branch local address B=20 > ----------------=20 > > >| > > > > > > SAM GLOBAL PREFIXES - GLOBAL ADDRESSES - LOCAL ADDRESSES > > > > Figure 4 > > > > Principles that influence the internal structure of branch > > identifiers proposed for SAM are the following: > > > > 1. To permit a flexible hierarchy of local zones, branch =20 > > identifiers > > should be kept rather short. They should, at least to some > > extent, be proportionate to the maximum number of branches > > supported in their zone. > > > > 2. Several subnets must be possible in the zone. For this, a =20 > > branch > > identifier contain an optional "subnet index" (S),=20 > followed the > > "branch index" (I) which identifies the branch in its subnet. > > (The word "index" is chosen to express that these=20 > fields have =20 > > no > > further internal structure.) > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 10] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > 3. For the efficiency of routing tables, intra-zone=20 > subnet indexes > > have to be in the upper part of local addresses,=20 > just behind =20 > > the > > "constant prefix" (P) that is common to all local=20 > addresses. =20 > > (In > > IPv6, this constant prefix can typically be an ULA prefix of > > [RFC4193]; in IPv4 is typically a private-address prefix of > > [RFC1918].) > > > > 4. For efficiency of the neighbor discovery protocol of=20 > [RFC2461], > > branch indexes B have on the contrary to be in the lowest =20 > > part of > > branch local addresses B. > > > > 5. Consequently, it must be possible to extract=20 > separately, from a > > intra-zone branch identifier iB, the subnet index S and the > > interface index I, and for this to know their=20 > lengths (s and =20 > > i). > > > > 6. In order to permit to configure several subnet-index lengths, > > and/or several interface index lengths, in SAM zones, an =20 > > optional > > branch-identifier "format code" (F) is placed at the =20 > > beginning of > > branch identifiers B (just before the optional=20 > subnet index S, > > and the branch index B). Each format codes=20 > specifies a subnet- > > index length s and an interface-index length i. =20 > Format codes T > > may have different lengths, but must be non overlapping =20 > > prefixes > > to be recognized. > > > > Since the local address B of a branch interface starts with a > > constant prefix P followed by the interface subnet index=20 > S , and is > > terminated by the interface-index of the interface, space is left > > between them. It is filled with a next-field delimiter (D). Its > > format, a series of 0s followed by a 1, i.e. 00...01=20 > with a minimal > > length of 1 bit, is chosen so that knowing the constant=20 > prefix P =20 > > and > > the subnet prefix of a branch interface, lengths s and i=20 > of the its > > subnet index S and of its interface index I can be determined. =20 > > Then, > > the identifier format F to be placed in global prefixes=20 > of B can be > > derived from these lengths s and i. > > > > 3.4. Endpoint global address to branch local address mapping > > > > Detailed steps by which a branch local address B is=20 > derived from =20 > > from > > the global address of a branch-side endpoint are presented in > > Figure 5. > > > > > > > > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 11] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > =20 > ________________________________________________________ > > | Endpoint Global =20 > > address | > > | =20 > > gE | > > |=20 > > ________________________________________________________| > > (A) ANALYSIS || > > \/ > > ___________________________________________=20 > ............ > > | Global | id | Subnet | branch | =20 > > endpoint : > > | prefix |Format| index | Index | =20 > > suffix : > > | G | F | S | I | =20 > > E : > > |_________|______|_________|=20 > > ________________|............: > > | | | | > > 1. Match found | | | | > > in the G list ___| | | | > > | | | > > 2. Match found | | | > > in the F list ______| | | > > | | > > 3. length defined by F _______| | > > . | > > 4. length defined by F ____________________| > > . . > > (B) CONSTRUCTION . || . > > . \/ . > > 5. The current . . > > local-address prefix __ . . > > | . . > > 6. From step 3. _______:______.__ . > > | | . > > 7. From step 4. _______:_________:_________.__________ > > | | | > > 8. Binary 00...01 _____:_________:________ | > > | | | | > > =20 > ______________|_________|________|___________|__________ > > | local-address | Subnet |next field | =20 > > branch | > > | Prefix | index | Delimiter | =20 > > Index | > > | P | S | D | =20 > > I | > > |_________________|_________|___________|=20 > > ________________| > > |<--------------- Branch Local address B=20 > ---------------=20 > > >| > > > > DERIVING A BRANCH LOCAL ADDRESS FROM AN ENDPOINT GLOBAL =20 > > ADDRESS > > > > Figure 5 > > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 12] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > 3.5. Privacy protection > > > > In a zone where privacy protection is desired, the=20 > privacy option =20 > > can > > be turned on. Principles of this option are the following: > > > > o Fields that identify branch-side IP endpoints in privacy =20 > > protected > > zones, or transport endpoints if endpoints are at=20 > this layer, =20 > > are > > obfuscated in e2e packets that traverse the the=20 > global Internet. > > > > o This obfuscation is stateless and reversible. > > > > o Branch SAMs of a privacy-protected zone are informed of =20 > > parameters > > of this obfuscation. They can thus know which "hidden" =20 > > addresses > > (or addresses plus ports), appear on the global Internet in =20 > > place > > of their "clear" addresses (or address plus ports). =20 > These clear > > addresses are those from which local addresses are=20 > derived in =20 > > the > > privacy-protected zone and in zones that are lower in the > > hierarchy. > > > > o In these lower zones, all branch SAMs are informed=20 > that a root =20 > > SAM > > in the global-Internet direction has activated a=20 > privacy option, > > and are informed of parameters of this option. They can thus > > derive a clear address (or address plus port) from an=20 > obfuscated > > address (or address plus port), and conversely. They can also > > avoid to activate the privacy so that obfuscation is=20 > never done > > more than once. > > > > Parameters of a privacy option are a privacy global=20 > prefix (PPm) =20 > > and > > a scrambling multiplier (PMm). The prefix is that which, at the > > beginning of global addresses, is not obfuscated in the global > > Internet. The multiplier is a 64 bit odd constant. > > > > Obfuscation consists in a modulo 2^n multiplication by the =20 > > scrambling > > multiplier, where n is the number of bits to be obfuscated. De- > > obfuscation is the modulo 2^n multiplication by the=20 > inverse of the > > scrambling multiplier (for odd numbers, such an inverse=20 > modulo 2^n > > always exists). > > > > In hosts in which the branch SAM is informed of an active privacy > > option, applications that ask for their address and their port at > > their socket interface, get them in hidden form, that=20 > which appears > > in the global Internet. The e2e principle is thus preserved =20 > > despite > > the fact that the topology of the privacy-protected zone=20 > and that =20 > > of > > lower zones in the hierarchy are all hidden, and despite the fact > > that successive transport connections from a same host=20 > cannot, in =20 > > the > > global Internet, be related to a single host. > > > > Ports that are concerned with the privacy option are=20 > only the IANA > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 13] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > defined dynamic and/or private ports (ports 49152 to 65535, those > > starting with binary 11). Well known ports and registered ports, > > which have an e2e meaning not to be lost must not be obfuscated. > > > > Since some applications, e.g. active mode FTP of=20 > [RFC0959], work on > > port pairs rather than on individual ports, port bits to be > > obfuscated must exclude the las one. Port bits that are part of > > obfuscated endpoint identifiers are then bits 2 to 14. > > > > > > > > gY > > ^ > > | > > ... > > e2e packet: gZ11.F2.hhhh->gY [TCP hh->80 [data]] > > ^ > > | > > gZkij ROOT ZONE R > > =20 > ___________________________:________________________ > > |(Z) .--> (root =20 > > SAM) | > > Privacy-option ON / =20 > > Rk | > > for prefix PP1 =3D gZkij.F1 ---' ^ LOCAL ZONE = =20 > > Z | > > with multiplier PM1 =20 > > | | > > | =20 > > | | > > =20 > > | ... | > > encapsulated | [ B->R [ gZkij.cccc->gY [TCP cc->80 =20 > > [data]] | > > packet =20 > > | | > > | =20 > > ^ | > > | =20 > > | | > > | =20 > > B | > > |=20 > > ___________________________:________________________| > > (branch SAM) > > Clear-address packet: gZkij.F1.cccc->gY [TCP=20 > cc->80 [data]] > > e2e packet: gZkij.F1.hhhh->gY [TCP=20 > hh->80 [data]] > > where tmp =3D modulo 2^m (PM1 x (cccc . (bits 2 to 14 of cc)) > > where m =3D length of cccc + length of cc - 3 > > hhhh =3D bits 0 to (length of hhhh - 1) of tmp > > hh =3D cc in which bits 2-15 are replaced by > > bits(length of PP1 TO m - 1) of tmp . > > > > SAM PRIVACY OPTION ILLUSTRATION > > > > Figure 6 > > > > Figure 6 illustrates the effect of the privacy option. The =20 > > option is > > supposed to be on, in the root SAM of the zone, for its global =20 > > prefix > > gZkij and its identifier format F1. The privacy-option prefix is > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 14] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > therefore PP1 =3D gZ11.F2. the scrambling multiplie ris PM1. > > > > 3.6. SAM parameters > > > > Table 3 to Table 5 of this section present the complete=20 > set of SAM > > parameters described in previous sections. > > > > +-----------------------+-----+ > > | constant local Prefix | TTL | > > +-----------------------+-----+ > > | ... | ... | > > | Pm | PTm | > > | ... | ... | > > +-----------------------+-----+ > > > > CONSTANT PREFIX PARAMETERS > > > > Table 1 > > > > +--------------------+-----+------------------=20 > > +---------------------+ > > | identifier Format | TTL | Subnet-index | Interface-=20 > > index | > > | code | | Length | =20 > > Length | > > +--------------------+-----+------------------=20 > > +---------------------+ > > | ... | ... | ... =20 > > | ... | > > | Fn | FTn | SLn | =20 > > ILn | > > | ... | ... | ... =20 > > | ... | > > +--------------------+-----+------------------=20 > > +---------------------+ > > > > IDENTIFIER-FORMAT PARAMETERS > > > > Table 2 > > > > +-----------------+-----+---------------+-----+---------------=20 > > +-----+ > > | Root local | TTL | Global Prefix | ... | Global Prefix =20 > > | ... | > > | address | | 1 | | j =20 > > | | > > +-----------------+-----+---------------+-----+---------------=20 > > +-----+ > > | ... | ... | ... | ... | ... =20 > > | ... | > > | Ri | RTi | gZi1 | ... | gZij =20 > > | ... | > > | ... | ... | ... | ... | ... =20 > > | ... | > > +-----------------+-----+---------------+-----+---------------=20 > > +-----+ > > > > ROOT PARAMETERS > > > > Table 3 > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 15] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > +--------------------+------+ > > | Global zone prefix | TTL | > > +--------------------+------+ > > | ... | ... | > > | gZij | GTij | > > | ... | ... | > > +--------------------+------+ > > > > GLOBAL-PREFIX PARAMETERS > > > > Table 4 > > > > +-----------------------+-----+---------------------------+ > > | Privacy-option Prefix | TTL | Privacy-option Multiplier | > > +-----------------------+-----+---------------------------+ > > | ... | ... | ... | > > | PPp | PTp | PMp | > > | ... | ... | ... | > > +-----------------------+-----+---------------------------+ > > > > PRIVACY-OPTION PARAMETERS > > > > Table 5 > > > > 3.7. Port-range-based extended IPv4 addressing > > > > For a dual stack host not to break the e2e principle when it > > establishes a connection with an remote endpoint that is=20 > still only > > reachable in IPv4, it must have a global IPv4 address. =20 > Because of > > the IPv4 address shortage, this address may however be=20 > shared with > > other hosts. For this, SAM accepts "port-extended" IPv4=20 > prefixes, > > longer than 32 bits. Bits beyond the first 32 define a port =20 > > range in > > the set of dynamic and/or private ports (those in which the two =20 > > high > > order bits are binary 11). For example, a 3-bit prefix=20 > extension =20 > > 010 > > imposes that branch-side hosts use only ports starting=20 > with binary > > 11010. > > > > Note that, due to the systematic encapsulation of global=20 > packets in > > local packets of SAM, routing within SAM zones is not concerned =20 > > with > > theses "port-extended" IPv4 addresses. Only root SAMs and branch > > SAMs have to know about of port ranges. > > > > The branch SAM in a host that is assigned a port-restricted IPv4 > > address has to inform its socket interface of the port range > > available to applications, and to inform its internal=20 > NAT if it has > > one. Consequences for applications, and for NATs, of=20 > restricted =20 > > port > > ranges, are out of the scope of this SAM specification. Other > > documents are available on the subject, e.g. [Boucadair], which > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 16] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > however requires further study. > > > > > > 4. SAM Application examples > > > > 4.1. Address independence in an IPv6 site > > > > In the example of Figure 7, we consider a home or SOHO site in =20 > > which > > an Ethernet and/or WiFi LAN is deployed. Its global=20 > IPv6 prefix gZ > > is 2001:0db8:9999::/48. > > > > Local addressing is done in an IPv6 private space. To=20 > keep address > > shorts in the figure, the constant prefix of these addresses is > > fc00/8, the shortest prefix reserved for private IPv6=20 > addressing in > > [RFC4193]. (This prefix could however be replaced by a=20 > full fdxx: > > xxxx:xxxx::/48 prefix, as recommended in [RFC4193] for ULAs, =20 > > without > > changing the substance of the example.) > > > > The site is configured to support 255 branch interfaces=20 > on the LAN > > (each branch being indifferently a host and/or a router). To > > facilitate future changes, a branch-identifier format code F1, =20 > > set to > > 0/4, is used in branch global prefixes. > > > > SAM parameters of the site are then following (ignoring TTLs): > > > > Constant local prefix: P1 =3D fc00/8 > > > > Identifier format code: F1 =3D 0::/4 > > > > Subnet index length: SL1 =3D 0 (non applicable) > > > > Interface index length: IL1 =3D 8 > > > > Root local address: R1 =3D fc00::0101 > > > > Zone Global prefix: gZ11 =3D 2001:0db8:9999::/48 > > > > Privacy option prefix: none in this example > > > > We now consider a SAM-capable PC which serves as a router for a > > bluetooth link. On this link, a bluetooth mobile phone=20 > is active. > > (Configuring a root-SAM in the PC would permit the=20 > mobile phone, if > > acting as a SAM-capable router, to assign global prefixes and > > addresses, to hosts behind it. But this would have been=20 > too much =20 > > for > > the example). > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 17] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > | > > | > > 2001:0db8:9999::/48 > > _________________:_________________ > > |(Z) (root SAM) for 2^8 hosts | > > Site | fc00::0101 | > > gateway | | > > | | > > | fc00::0155 | > > |_________________:_________________| > > | > > Ethernet and/or WiFi ... > > fcOO::/64 | > > > > fc00::0155 > > (branch SAM) > > =3D> + 2001:0db8:9999:0550::/60 > > __________:__________ > > |2001:0db8:9999:0558::| > > PC | | > > |_____________________| > > /___________._________/ > > | > > Bluetooth ... > > 2001:0db8:9999:0550::/64 | > > | > > 2001:0db8:9999:0550:< eui64 IID > > > | > > |_|__ > > | | > > Mobile phone | | > > | | > > |_____| > > > > Figure 7 > > > > The PC local address B is fc00::0155, i.e. P.D.I where P is > > fc00::/8, where the 8 bits of I are supposed to be 55::/8, and =20 > > where > > D is binary 00...01 with consequently (128 - 8 -8) =3D 112 bits. > > > > The PC global prefix gB is therefore=20 > 2001:0db8:9999:0550::/60, i.e. > > G.F.I, where G is 2001:0db8:9999::/48, where F is 0::/4, and =20 > > where I > > is 55::/8. > > > > The PC global address is therefore=20 > 2001:0db8:9999:0558::, i.e. gB.E > > where E is binary 10...00 with (128 - 48 - 4 - 8) =3D 68 bits. > > > > The bluetooth link is supposed to have 0::/4 as subnet=20 > ID in the =20 > > PC. > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 18] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > Its /64 subnet prefix is therefore 2001:0db8:9999:0550::/64. > > > > This simple example illustrates how the SAM logic permits to > > establish a hierarchy of routing zones where each host=20 > can become a > > router, and where the e2e principle is preserved. > > > > 4.2. Multihoming and extended IPv4 addressing in a home site > > > > In the example of Figure 8, we consider a home site S, multihomed > > with two ISPs A and B. > > > > ISP A assigns to the site IPv6 prefix=20 > 2001:1111:1111:1110::/60, and > > IPv4 address 192.0.2.1. > > > > ISP B can only assign port-restricted IPv4 addresses to its sites > > because it has to support up to 2^16 sites, and has only=20 > for this =20 > > an > > IPv4 /18 prefix (namely 198.16.0.0/18, i.e.=20 > v4|c610:0000:/18), and > > since 18 + 16 =3D 34 which exceeds 32. Having=20 > 2001:0db8::/32 as its > > IPv6 prefix, it assigns /48s to its customer sites, in particular > > 2001:0db8:0202::/48 to site S. > > > > Half of its IPv4 address space, namely v4|c608:c000/19=20 > is allocated > > to a NAT to support sites that are not SAM capable. The other =20 > > half, > > i.e. v4|c610:2000/19, is allocated to a root SAM, the=20 > local address > > of which is supposed to be 2001:0db8::1. > > > > SAM parameters of the zone of ISP B are then the following: > > > > Constant local prefix: P1 =3D 2001:0db8: =3D v4|a000::/8 > > > > Identifier format code: F1 =3D ::/0 (non applicable) > > > > Subnet index length: SL1 =3D 0 (non applicable) > > > > Interface index length: IL1 =3D 16 > > > > Root local address: R1 =3D 2001:0db8::1:1 > > > > Zone Global prefix: gZ11 =3D v4|c608:8000/19 = (=3D198.8.128.0/19). > > > > Privacy option prefix: none in this example (::/0) > > > > > > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 19] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > 198.16.0.0/18 > > 2001:0db8::/32 =20 > =3Dv4|c610:0000:/18 > > =20 > ____|__________________|____________ > > |(B) / =20 > > \ | > > | | v4|=20 > > c610:2000/19 | > > | v4|c608:c000/19 =20 > > | | > > | (NAT) (root =20 > > SAM) | > > | 0.0.0.0/0 =20 > > 2001:0db8::1 | > > |(A) | =20 > > | | > > | | =20 > > | | > > |2001:1111:1111:1110::/60| | (2^16 SAM =20 > > sites) | > > | 192.0.2.1 | =20 > > | | > > | =3Dv4|c000:0201/32 | | =20 > > 2001:0db8:0202::/48 | > > |________________:_______| |=20 > > ___________________:________________| > > | (branch SAM) > > | =3D> + v4|c610:2040:4000::/35 > > | =3D 198.8.128.64/ports 11010... > > =20 > ________________:______________________________:________________ > > |(S) / \ / =20 > > \ | > > | | v4|c000:0201:0000::/33 | v4|=20 > > c610:2040:4000::/36| > > | | ::/0 | ::/=20 > > 0 | > > | v4|c600:0201:8000::/33 | v4|c608:2040:6000::/36 =20 > > | | > > | (NAT) (root SAM) (NAT) (root =20 > > SAM) | > > | 0.0.0.0/0 fc00::0011 0.0.0.0/0 =20 > > fc00::0012 | > > =20 > > | | > > | (2^4 SAM =20 > > hosts) | > > | =20 > > fc00::0018 | > > |=20 > > _____________________________:__________________________________| > > | > > HOST (H) (branch SAM) > > =3D> + 2001:1111:1111:1118:8000::0008/64 > > + 2001:0db8:0220:4800::0008/52 > > + v4|c000:0201:4000::/37 =3D 192.0.2.1 ports 1101000... > > + v4|c610:2040:5000::/40 =3D 198.16.32.64 ports=20 > 1101001000... > > : > > HOST > > > > PRIVATE-ADDRESSING- AND DUAL-HOMING- SITE WITH E2E CAPABILITY > > > > Figure 8 > > > > In site S, the branch SAM of its root interface with ISP=20 > B derives > > from its IPv6 prefix 2001:0db8:O2O2::/48, and from SAM=20 > parameters =20 > > of > > ISP B, its IPv4 prefix v4|c610:2040:4000::/35, which is a port- > > restricted one. > > > > Two root SAMs are configured in site S. Its=20 > local-address constant > > prefix is fc00::/8 as. Half of the each available IPv4=20 > addressing > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 20] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > space is reserved for a NAT, and the other half for a root SAM. > > > > Parameters of SAMs of site S are then the following: > > > > Constant local prefix: P1 =3D fc00/8 > > > > Identifier format code: F1 =3D 0::/4 > > > > Subnet index length: SL1 =3D 0 > > > > Interface index length: IL1 =3D 8 > > > > Root local addresses: R1 =3D fc00::0011; R2 =3D fc00::0012 > > > > Zone Global prefixes: gZ11 =3D=20 > 2001:1111:1111:1110::/60; gZ12 =3D =20 > > v4| > > c000:0201/32; gz21 =3D 2001:0db8:0202::/48; gZ22 =3D v4| > > c610:2040:4000::/35 > > > > Privacy option prefix: none in this example (::/0) > > > > Among the 16 hosts of home site S, Host H is supposed to=20 > have local > > address fc00::0018. As shown on the figure, the branch SAM of =20 > > host H > > then derives from this local address two IPv6 global=20 > prefixes, two > > IPv6 global host addresses starting with these prefixes, and two > > port-restricted IPv4 prefixes. With these prefixes, it can use, > > without breaking the e2e principle, 512 ports for=20 > connections via =20 > > ISP > > A, and 64 ports via ISP B. > > > > > > 5. SAM as an alternative to NATs in IPv6 > > > > With SAM as specified, all NAT44 services that have been=20 > listed in > > Section 2 can be offered in IPv6 without stateful processing and > > without breaking the e2e principle: > > > > 1. In a private-addressing IPv6 site, hosts can know=20 > their global > > addresses to use them in e2e packets that are encapsulated in > > local packets to traverse the site. Renumbering is then > > automated simply by automating advertisement of SAM parameter > > changes (in DHCP and/or with router advertisements). > > > > 2. The fact that NAT44s are in general configured with=20 > by default > > rejection of all incoming calls can have a simple stateless > > equivalent in IPv6: > > > > * By default, reject all incoming packets that have=20 > a branch- > > side port in the well known or in the IANA defined =20 > > registered > > port ranges. > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 21] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > * By default, reject all TCP incoming packets that are =20 > > attempts > > to open new incoming connections (SYN packets=20 > without ACK). > > > > 3. In a SAM-capable site, SAM-capable hosts can take=20 > advantage of > > site multihoming with full compatibility with=20 > ingress filtering > > of [RFC3704] in both the site itself and in ISP networks to =20 > > which > > it is connected. > > > > 4. The privacy protection described in Section 3.5=20 > maintains the =20 > > e2e > > principle. It is expected to be largely sufficient in =20 > > practice. > > (Sophisticated hackers would probably find ways=20 > around it, and > > identify who does what in sites havin the privacy-protection > > option, but NAT44s are not perfect for privacy protection > > either). > > > > 5. As we have seen, SAM global addresses contain a flexible > > succession of branch identifiers, so that it becomes=20 > possible =20 > > to > > set up a flexible hierarchy of private addressing zones. In > > particular, host-rooted subnets become possible without =20 > > breaking > > the e2e principle. > > > > For information, no intellectual property right has been=20 > applied =20 > > for > > by the author on any of SAM mechanisms. The intent is to =20 > > facilitate > > IPv6 deployment with new mechanisms that still enhance its =20 > > potential. > > > > > > 6. Security considerations > > > > Like any function where some parameters have to be=20 > configured, SAM > > introduces a risk of human errors. > > > > Besides that, no security risk introduced by SAM has so far been > > identified. In particular: > > > > Provided consistency between local addresses present in =20 > > encapsulating > > packets and global addresses present in encapsulated packets are > > systematic, no more address spoofing is possible than=20 > without SAM. > > > > Due to the stateless operation of SAM, its scalability is high. > > Prevention against denial of service attacks should therefore =20 > > remain > > easy even for very intense traffic (e.g. using load balancers in > > front of parallel devices). > > > > > > 7. IANA Considerations > > > > If and when this specification is stabilized and approved, option > > codes in DHCP, DHCPv6, and ND will have to be defined to > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 22] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > automatically convey SAM parameters to branch SAMs. > > > > > > 8. Acknowledgements > > > > As this specification has evolved during many months, precious > > encouragement and remarks were received from Mark=20 > Townsley. He has > > to be warmly thanked for it. Concerning what SAM can bring to =20 > > port- > > restricted IPv4 addresses, stimulating discussions with Dan Wing, > > Teemu Savolainen, Gabor Bajko, Pierre Levis, Jean-Luc=20 > Grimault, and > > Alain Villefranque, have influenced progress of the work. =20 > > Gratitude > > is due to them for this. Challenging remarks, and a few=20 > (deserved) > > criticisms from Alain Durand have also helped to better=20 > analyze how > > SAM will coexist with NATs. He deserves credit for it. > > > > > > 9. References > > > > 9.1. Normative References > > > > [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D.,=20 > Groot, G., =20 > > and > > E. Lear, "Address Allocation for Private Internets", > > BCP 5, RFC 1918, February 1996. > > > > [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", > > RFC 2131, March 1997. > > > > [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T.,=20 > Perkins, C., > > and M. Carney, "Dynamic Host Configuration=20 > Protocol for > > IPv6 (DHCPv6)", RFC 3315, July 2003. > > > > [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast > > Addresses", RFC 4193, October 2005. > > > > [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, > > "Neighbor Discovery for IP version 6 (IPv6)",=20 > RFC 4861, > > September 2007. > > > > 9.2. Informative References > > > > [6rd] Despres, R., "IPv6 Rapid Deployment on IPv4 > > infrastructures (6rd) - Work in progress > > (draft-despres-6rd-02)", October 2008. > > > > [Boucadair] > > Boucadair, M., Grimault, J-L., Levis, P., and A. > > Villefranque, "Behaviour of BitTorrent=20 > service in an IP > > Shared Address Environment > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 23] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > =20 > (draft-boucadair-behave-bittorrent-portrange-02 - work =20 > > in > > progress)", january 2009. > > > > [LISP] Farinaci, D., Fuller, V., Oran, D., Meyer, D., and S. > > Brim, "Locator/ID Separation Protocol (LISP) - > > draft-farinacci-lisp-09", December 2008. > > > > [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", > > STD 9, RFC 959, October 1985. > > > > [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor > > Discovery for IP Version 6 (IPv6)", RFC 2461, > > December 1998. > > > > [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address > > Translator (NAT) Terminology and Considerations", > > RFC 2663, August 1999. > > > > [RFC3056] Carpenter, B. and K. Moore, "Connection of=20 > IPv6 Domains > > via IPv4 Clouds", RFC 3056, February 2001. > > > > [RFC3286] Ong, L. and J. Yoakum, "An Introduction to the Stream > > Control Transmission Protocol (SCTP)", RFC 3286, May =20 > > 2002. > > > > [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for=20 > IPv6 Site- > > Multihoming Architectures", RFC 3582, August 2003. > > > > [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for =20 > > Multihomed > > Networks", BCP 84, RFC 3704, March 2004. > > > > [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) =20 > > Developers > > Should Think About", RFC 4219, October 2005. > > > > [RFC4301] Kent, S. and K. Seo, "Security Architecture for the > > Internet Protocol", RFC 4301, December 2005. > > > > [RFC4864] Van de Velde, G., Hain, T., Droms, R.,=20 > Carpenter, B., =20 > > and > > E. Klein, "Local Network Protection for=20 > IPv6", RFC 4864, > > May 2007. > > > > [RFC4960] Stewart, R., "Stream Control Transmission Protocol", > > RFC 4960, September 2007. > > > > [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site > > Automatic Tunnel Addressing Protocol (ISATAP)", RFC =20 > > 5214, > > March 2008. > > > > [Shim6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3=20 > Multihoming > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 24] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > Shim Protocol for IPv6 - Work in progress > > (draft-ietf-shim6-failure-detection-09)",=20 > October 2007. > > > > [draft-carpenter-renum-needs-work-01] > > Carpenter, B., Atkinson, R., and H. Flinck,=20 > "Renumbering > > still needs work - Work in progress", December 2008. > > > > [shim6 fail detec] > > Arkko, J. and I. van Beijnum, "Failure Detection and > > Locator Pair Exploration Protocol for IPv6=20 > Multihoming - > > Work in progress (draft-ietf-shim6-failure-=20 > > detection-09)", > > July 2007. > > > > > > Author's Address > > > > Remi Despres > > 3 rue du President Wilson > > Levallois, > > France > > > > Email: remi.despres@free.fr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 25] > > > > > > Internet-Draft Stateless Address Mapping (SAM) =20 > November =20 > > 2008 > > > > > > Full Copyright Statement > > > > Copyright (C) The IETF Trust (2008). > > > > This document is subject to the rights, licenses and restrictions > > contained in BCP 78, and except as set forth therein, the authors > > retain all their rights. > > > > This document and the information contained herein are provided =20 > > on an > > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =20 > > REPRESENTS > > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE=20 > IETF TRUST =20 > > AND > > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, =20 > > EXPRESS > > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE =20 > > USE OF > > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR=20 > ANY IMPLIED > > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=20 > PARTICULAR PURPOSE. > > > > > > Intellectual Property > > > > The IETF takes no position regarding the validity or scope of any > > Intellectual Property Rights or other rights that might be =20 > > claimed to > > pertain to the implementation or use of the technology=20 > described in > > this document or the extent to which any license under=20 > such rights > > might or might not be available; nor does it represent=20 > that it has > > made any independent effort to identify any such rights. =20 > > Information > > on the procedures with respect to rights in RFC documents can be > > found in BCP 78 and BCP 79. > > > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission for the =20 > > use of > > such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR =20 > > repository at > > http://www.ietf.org/ipr. > > > > The IETF invites any interested party to bring to its=20 > attention any > > copyrights, patents or patent applications, or other proprietary > > rights that may cover technology that may be required to=20 > implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org. > > > > > > > > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 =20 > [Page =20 > > 26] > > > > _______________________________________________ > > 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 Mon Mar 16 20:43: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 7F9623A6898 for ; Mon, 16 Mar 2009 20:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 5JTIWyO70MYi for ; Mon, 16 Mar 2009 20:43:07 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id B53C43A677C for ; Mon, 16 Mar 2009 20:43:07 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id l9so3131102rvb.49 for ; Mon, 16 Mar 2009 20:43:49 -0700 (PDT) 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=RLfOzIApnMG7csD4hcAD6SfrmHWguTLIemPlCBenEaQ=; b=TmKwQMoSNyhsuvM+7ZziFCZEmynbTFMNkqZMclsCJRIcJmvgQWTGqD1KgxhmOsbafG /vD6qp+Ux6H3Y3WJ0crr5cZc+LQjUy0oKlZEG53JbPI/TH2ZZzKmA+I3CUHvzP+3OeNs ZX0cyfTBTV5zcl3HUrdt3JJo3tb1LrG+iisY0= 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=KqnCCErt/0a+KvK+/QlS45gbWXTv/jpBY72vwf/aeuXmcvVtxb0iyorFGMriQkSthC JysRYtp4WeSjQ965DhZN8a+i+wHEGXb08rby9wHYW1IHp4xYR+E7MDTle0wT4A4/bVbE 8V5nupGC8WUkEU+7gmRTqhjmbq+prlDshS3xk= Received: by 10.115.91.11 with SMTP id t11mr3880213wal.117.1237261429909; Mon, 16 Mar 2009 20:43:49 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id v32sm5714086wah.17.2009.03.16.20.43.47 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Mar 2009 20:43:49 -0700 (PDT) Message-ID: <49BF1C5D.6050900@gmail.com> Date: Tue, 17 Mar 2009 16:43:25 +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: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> <49B4CC0F.5040304@it.uc3m.es> <07f401c9a0f3$eff5cbd0$c2f0200a@cisco.com> <49B63DA3.4000707@it.uc3m.es> In-Reply-To: <49B63DA3.4000707@it.uc3m.es> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mohamed.boucadair@orange-ftgroup.com, behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Tue, 17 Mar 2009 03:43:08 -0000 On 2009-03-10 23:14, marcelo bagnulo braun wrote: ... >> In all three of those cases, Host-C could make good use of Host-B's >> IPv4 address. > > one more question about this... > > how does Host A knows that Pref64_1:IPB:suffix is indeed a > representation of an IPv4 address in IPv6? > In order to do that, it needs to know the prefix used for that > again, we are int he situation that host A needs to discover the > prefix64 in order to identify this is a represetnation of an IPv4 > address in IPv6. > So the host A would need to implement the discover provedures if the LIR > prefix is used Reading that and some earlier comments in this thread, it seems to me that we might consider defining a generic 'referral object', containing more information than just an address, that could be passed among application entities. It could contain TLVs that would provide the semantics of the referred address as well as the raw address bits. Does this seem worth exploring? Brian From dwing@cisco.com Mon Mar 16 22:04: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 672D13A67C1 for ; Mon, 16 Mar 2009 22:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.242 X-Spam-Level: X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 oxSdETN2lbFg for ; Mon, 16 Mar 2009 22:04:43 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 98AE03A6452 for ; Mon, 16 Mar 2009 22:04:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,376,1233532800"; d="scan'208";a="143248285" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 17 Mar 2009 05:05:26 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2H55QbU032017; Mon, 16 Mar 2009 22:05:26 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2H55Q6G026794; Tue, 17 Mar 2009 05:05:26 GMT From: "Dan Wing" To: "'Brian E Carpenter'" , "'marcelo bagnulo braun'" References: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> <49B4CC0F.5040304@it.uc3m.es> <07f401c9a0f3$eff5cbd0$c2f0200a@cisco.com> <49B63DA3.4000707@it.uc3m.es> <49BF1C5D.6050900@gmail.com> Date: Mon, 16 Mar 2009 22:05:26 -0700 Message-ID: <005101c9a6bd$fc167610$c2f0200a@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: AcmmspWJ0wvQOFKYQZKMb+A0mTb7zQAAfM1w In-Reply-To: <49BF1C5D.6050900@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1410; t=1237266326; x=1238130326; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20comment=20about=20draft-wing -behave-nat64-referrals-00.txt |Sender:=20; bh=QQBl0EA04o2V4kn8T0v8BpCJ0P2r47E83Fv/CxzWZfU=; b=hklS4V9XB1bu1cw5c4k1QTwoGx+GNjlBaOTWaxre4vhxE2vVA5j9XC+4W0 WXgBParf3i3/NZG4rXCOH1xIORYVAsu2pd/r153/sWNq0d67PuchtHF+ZXhZ BmIvV28XEt; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mohamed.boucadair@orange-ftgroup.com, behave@ietf.org Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Tue, 17 Mar 2009 05:04:47 -0000 > On 2009-03-10 23:14, marcelo bagnulo braun wrote: > ... > >> In all three of those cases, Host-C could make good use of Host-B's > >> IPv4 address. > > > > one more question about this... > > > > how does Host A knows that Pref64_1:IPB:suffix is indeed a > > representation of an IPv4 address in IPv6? > > In order to do that, it needs to know the prefix used for that > > again, we are int he situation that host A needs to discover the > > prefix64 in order to identify this is a represetnation of an IPv4 > > address in IPv6. > > So the host A would need to implement the discover > provedures if the LIR > > prefix is used > > Reading that and some earlier comments in this thread, it seems to me > that we might consider defining a generic 'referral object', > containing > more information than just an address, that could be passed among > application entities. It could contain TLVs that would provide the > semantics of the referred address as well as the raw address bits. > > Does this seem worth exploring? Yes, this could form the basis for very useful guidance to application designers. ICE does something like this already, but abstracting its functions up several levels, as you propose, would be useful. Something like: "here is my IPv4 address, it goes through a translator so avoid using it if you can utilize my IPv6 address" and so on. -d From remi.despres@free.fr Tue Mar 17 01:40: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 B227E3A6AB1; Tue, 17 Mar 2009 01:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_22=0.6, 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 cL0HR7ddgsYy; Tue, 17 Mar 2009 01:40:50 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 3FDA13A6AB0; Tue, 17 Mar 2009 01:40:47 -0700 (PDT) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id D95A78181CE; Tue, 17 Mar 2009 09:41:25 +0100 (CET) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp3-g21.free.fr (Postfix) with ESMTP id C3C08818179; Tue, 17 Mar 2009 09:41:22 +0100 (CET) Message-ID: <49BF61B1.10302@free.fr> Date: Tue, 17 Mar 2009 09:39:13 +0100 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Margaret Wasserman References: <49BA2DD6.8080001@free.fr> <96B651AC-8244-44DF-8937-2FB79C119B49@lilacglade.org> In-Reply-To: <96B651AC-8244-44DF-8937-2FB79C119B49@lilacglade.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Softwires WG , Behave WG , Internet Area Subject: Re: [BEHAVE] FYI: draft-despres-sam-02 enclosed X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2009 08:40:51 -0000 Margaret Wasserman - le (m/j/a) 3/17/09 1:13 AM: > > Hi Remi, > > I have a few high-level comments/questions on this draft from my first > reading, and I may have more after I have reviewed it in more detail. > > (1) You have indicated that you would like to discuss this draft in > the 6AI BOF, but you have not cc:ed the mailing list for the 6AI BOF > (nat66@ietf.org). Also, have you talked to the chairs of the 6AI BOF > (Bob Hinden and Dan Wing) about whether they are willing to include > this draft on the agenda, despite the fact that it has not been posted > to the I-D archive? There doesn't appear to be an agenda online for > the 6AI BOF yet, so I am not sure if it will be included. I started with the NAT66 mailing list, and only followed with WG lists. See also Dan's answer. > > (2) The end hosts in the SAM system need to know their globally > routable addresses, so how can SAM be said to provide address > independence? Routing within the site is based on local addresses, e.g. ULAs. That's only in SAM-capable CPEs and in SAM-capable hosts that, knowing SAM parameters, global-address packets can be encapsulated in local-address packets. > (3) Exactly what formulation of the end-to-end principle are you > referring to in this paper when you indicate that SAM preserves it in > IPv6? Thanks for the remark. There should be a reference, e.g. to RFC 1958. What is meant is IP-layer network transparency, e2e. Addresses and ports that are seen by two communicating applications must be the same at both ends. > My understanding of the end-to-end principle is that it has to do with > putting intelligence at the edges of the network (in hosts vs. > routers/middleboxes) and with putting certain function at the top of > the protocol stack (apps layer vs. lower layers). This is based on my > understanding (and recollection) of a paper by Jerry Saltzer, D. Reed > and Dave Clark written in the mid 1980s, which you can find here: > > http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt > > It is also reasonably well-summarized in this Wikipedia article. > > http://en.wikipedia.org/wiki/End-to-end_principle > > Based on my understanding of the end-to-end principle, I don't see any > significant difference in SAM vs. NAT66 WRT how much they maintain (or > violate) the end-to-end principle, as both mechanisms place some > functions/intelligence in the infrastructure. With SAM, hosts know their global addresses, and can use them, e.g. with SCTP or Shim6. In my understanding, this is a difference (an an important one). Regards, RD From dwing@cisco.com Tue Mar 17 08:57: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 0EBAD3A69EC for ; Tue, 17 Mar 2009 08:57:48 -0700 (PDT) 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=[AWL=0.350, 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 1OMgygdRPWmd for ; Tue, 17 Mar 2009 08:57:47 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 479CE3A68AB for ; Tue, 17 Mar 2009 08:57:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,379,1233532800"; d="scan'208";a="67751953" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 17 Mar 2009 15:58:30 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2HFwUI7024105 for ; Tue, 17 Mar 2009 08:58:30 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2HFwUpe013038 for ; Tue, 17 Mar 2009 15:58:30 GMT From: "Dan Wing" To: Date: Tue, 17 Mar 2009 08:58:30 -0700 Message-ID: <017601c9a719$377b7ab0$c2f0200a@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: AcmnGTdLzAl0waWiSXCi0/84AU0LXw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1005; t=1237305510; x=1238169510; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20Learning=20the=20IPv6=20Prefix=20of=20a=20NAT64 =20(draft-wing-behave-learn-prefix-01) |Sender:=20; bh=ezJCiU3O5Fzb3XDRjiqqop4aUQDJwk0aewWoRkcT6Ts=; b=amObEyckigv6mgVoNGAJp1fxZbhikID+kVSOa3lIePKrZbY+gOl87r1Tnj xwkxk5fKGjXWj3k5BnHDGo3Jbdp5G+1V5VZgCB1hb6ntFQjtCmRQ2BdIl/9e mbUPDRRwcJdLE4OOi/LKdXVrwlKhXVppCR0zHaaw6/7rL6vUFheUw=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [BEHAVE] Learning the IPv6 Prefix of a NAT64 (draft-wing-behave-learn-prefix-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: Tue, 17 Mar 2009 15:57:48 -0000 Last week I submitted a new version of "Learning the IPv6 Prefix of a NAT64", http://tools.ietf.org/html/draft-wing-behave-learn-prefix-01. It describes how an application can learn the prefix of its NAT64 via DNS or via DHCP. The DNS query would be sent to its DNS server, which is its DNS64 if the service provider is running a DNS64+NAT64. DHCP is per-interface. Both the DNS and DHCP methods allow the host to choose different NAT64s for different purposes (cost, performance, type of link). The significant change in this version is that a DNS NAPTR query is sent, rather than querying for a TXT record. I do not intend to present this document in San Francisco. Rather, this document exists to show it is possible for applications to learn the NAT64 prefix if they need to construct synthetic IPv6 addresses themselves. So far, only three applications have been identified which might benefit from this functionality: DNSSEC, BitTorrent, and SIP. Comments welcome. -d From brian.e.carpenter@gmail.com Tue Mar 17 20:43: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 ECF7A3A6873 for ; Tue, 17 Mar 2009 20:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 rdY7E2LCTf3d for ; Tue, 17 Mar 2009 20:43:56 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id 10E023A6ACE for ; Tue, 17 Mar 2009 20:43:55 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so374882and.4 for ; Tue, 17 Mar 2009 20:44:39 -0700 (PDT) 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=5owdg+vb5zhY+HWV5FsBYRBrvp/BXT56CLdsoM2lHQQ=; b=N4C9SFejgNZ98OdynR3txbJSmvUw7mUhJKG/Rzemo5vuLOK+488mdfSuKzjFnUAHVK fOgkNAOFFs5KcyHShgndN+fMP0IcgYLzGVQ7+Lsn9qXQmjgVlmOoz9xK7qcjvhPO7FGC PUdki+EzAP8IbvlkNgU4lZqBBYYRor4Z0/iZY= 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=KlJNmRUFQCnxSUYZHTsRcjrYk9asgCppIw/20NE/biYYZFrbR1vIBsWhui2PbHe54x Xl/PHT8avZM1V7mCT0BBXfqzodaEj+deNXNm1N4e5+XRMfbnt+mieq+5Wv294VljYHJe rS00EYGa4NnBfZlDubLo+agK2m3Vfina2J7LQ= Received: by 10.142.199.15 with SMTP id w15mr304972wff.66.1237347879059; Tue, 17 Mar 2009 20:44:39 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 30sm2570972wfd.35.2009.03.17.20.44.37 (version=SSLv3 cipher=RC4-MD5); Tue, 17 Mar 2009 20:44:38 -0700 (PDT) Message-ID: <49C06E25.4020006@gmail.com> Date: Wed, 18 Mar 2009 16:44:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> <49B4CC0F.5040304@it.uc3m.es> <07f401c9a0f3$eff5cbd0$c2f0200a@cisco.com> <49B63DA3.4000707@it.uc3m.es> <49BF1C5D.6050900@gmail.com> <005101c9a6bd$fc167610$c2f0200a@cisco.com> In-Reply-To: <005101c9a6bd$fc167610$c2f0200a@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mohamed.boucadair@orange-ftgroup.com, behave@ietf.org Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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: Wed, 18 Mar 2009 03:43:57 -0000 On 2009-03-17 18:05, Dan Wing wrote: >> On 2009-03-10 23:14, marcelo bagnulo braun wrote: >> ... >>>> In all three of those cases, Host-C could make good use of Host-B's >>>> IPv4 address. >>> one more question about this... >>> >>> how does Host A knows that Pref64_1:IPB:suffix is indeed a >>> representation of an IPv4 address in IPv6? >>> In order to do that, it needs to know the prefix used for that >>> again, we are int he situation that host A needs to discover the >>> prefix64 in order to identify this is a represetnation of an IPv4 >>> address in IPv6. >>> So the host A would need to implement the discover >> provedures if the LIR >>> prefix is used >> Reading that and some earlier comments in this thread, it seems to me >> that we might consider defining a generic 'referral object', >> containing >> more information than just an address, that could be passed among >> application entities. It could contain TLVs that would provide the >> semantics of the referred address as well as the raw address bits. >> >> Does this seem worth exploring? > > Yes, this could form the basis for very useful guidance to application > designers. ICE does something like this already, but abstracting its > functions up several levels, as you propose, would be useful. > > Something like: "here is my IPv4 address, it goes through a > translator so avoid using it if you can utilize my IPv6 address" > and so on. Yes, but make the format extensible. Unofficial bar BOF in SF? Brian From wangxuewei@huawei.com Thu Mar 19 02:02: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 F03923A6B3F for ; Thu, 19 Mar 2009 02:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=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 jDRqQfvP2Tt1 for ; Thu, 19 Mar 2009 02:02:40 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 989FC3A68FE for ; Thu, 19 Mar 2009 02:02:39 -0700 (PDT) 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 <0KGQ00KXZX5N9D@szxga04-in.huawei.com> for behave@ietf.org; Thu, 19 Mar 2009 17:03:23 +0800 (CST) Received: from w00104636 ([10.111.12.168]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGQ00L93X5M86@szxga04-in.huawei.com> for behave@ietf.org; Thu, 19 Mar 2009 17:03:23 +0800 (CST) Date: Thu, 19 Mar 2009 17:03:22 +0800 From: wangxuewei To: Dan Wing , behave@ietf.org Message-id: <015801c9a871$8e723530$a80c6f0a@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.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_g6yeZsLPDxzbQBR3rnRQsA)" X-Priority: 3 X-MSMail-priority: Normal References: <017601c9a719$377b7ab0$c2f0200a@cisco.com> Subject: Re: [BEHAVE] Learning the IPv6 Prefix of a NAT64(draft-wing-behave-learn-prefix-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: Thu, 19 Mar 2009 09:02:45 -0000 This is a multi-part message in MIME format. --Boundary_(ID_g6yeZsLPDxzbQBR3rnRQsA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT hi, read through your draft draft-wing-behave-learn-prefix-01 ,the IPv6 prefix and the prefix length can be learned using DNS or DHCP. what i think is there exists another method of learning the prefix and length by Router Advertisement (RA) message, for the IPv6 host attaches to the same multicast link as AFT, AFT can directly periodically advertise(or in response to valid Router Solicitations) RA messages containing the /96 prefix and length to the IPv6 host. For the IPv6 host attaches to the different multicast link with AFT, we can make AFT use dynamic routing protocol (OSPF?ISIS etc) to announce the /96 prefix and length to edge routers in the IPv6 domain, thus edge routers in the IPv6 domain obtain the /96 prefix and length, they can periodically advertise(or in response to valid Router Solicitations) RA messages containing the /96 prefix and length. how do you think this method ? thanks Xuewei Wang ----- Original Message ----- From: Dan Wing To: behave@ietf.org Sent: Tuesday, March 17, 2009 11:58 PM Subject: [BEHAVE] Learning the IPv6 Prefix of a NAT64(draft-wing-behave-learn-prefix-01) Last week I submitted a new version of "Learning the IPv6 Prefix of a NAT64", http://tools.ietf.org/html/draft-wing-behave-learn-prefix-01. It describes how an application can learn the prefix of its NAT64 via DNS or via DHCP. The DNS query would be sent to its DNS server, which is its DNS64 if the service provider is running a DNS64+NAT64. DHCP is per-interface. Both the DNS and DHCP methods allow the host to choose different NAT64s for different purposes (cost, performance, type of link). The significant change in this version is that a DNS NAPTR query is sent, rather than querying for a TXT record. I do not intend to present this document in San Francisco. Rather, this document exists to show it is possible for applications to learn the NAT64 prefix if they need to construct synthetic IPv6 addresses themselves. So far, only three applications have been identified which might benefit from this functionality: DNSSEC, BitTorrent, and SIP. Comments welcome. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --Boundary_(ID_g6yeZsLPDxzbQBR3rnRQsA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
hi,
read through your draft draft-wing-behave-learn-prefix-01 ,the IPv6 prefix and the prefix length can be learned using DNS or DHCP.
 
what i think is there exists another method of learning the prefix and length by Router Advertisement (RA) message, for the IPv6 host attaches to the same multicast link as AFT, AFT can directly periodically advertise(or in response to valid Router Solicitations) RA messages containing the /96 prefix and length to the IPv6 host.
For the IPv6 host attaches to the different multicast link with AFT, we can make AFT use dynamic routing protocol (OSPF、ISIS etc) to announce the /96 prefix and length to edge routers in the IPv6 domain, thus edge routers in the IPv6 domain obtain the /96 prefix and length, they can periodically advertise(or in response to valid Router Solicitations) RA messages containing the /96 prefix and length.
how do you think this method ?
thanks
 
 
Xuewei Wang
----- Original Message -----
From: Dan Wing
Sent: Tuesday, March 17, 2009 11:58 PM
Subject: [BEHAVE] Learning the IPv6 Prefix of a NAT64(draft-wing-behave-learn-prefix-01)

Last week I submitted a new version of "Learning the IPv6 Prefix of a NAT64",
http://tools.ietf.org/html/draft-wing-behave-learn-prefix-01.  It describes
how an application can learn the prefix of its NAT64 via DNS or via DHCP.  The
DNS query would be sent to its DNS server, which is its DNS64 if the service
provider is running a DNS64+NAT64.  DHCP is per-interface.  Both the DNS and
DHCP methods allow the host to choose different NAT64s for different purposes
(cost, performance, type of link).

The significant change in this version is that a DNS NAPTR query is sent,
rather than querying for a TXT record.

I do not intend to present this document in San Francisco.  Rather, this
document exists to show it is possible for applications to learn the NAT64
prefix if they need to construct synthetic IPv6 addresses themselves.  So far,
only three applications have been identified which might benefit from this
functionality:  DNSSEC, BitTorrent, and SIP.

Comments welcome.

-d

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave
--Boundary_(ID_g6yeZsLPDxzbQBR3rnRQsA)-- From magnus.westerlund@ericsson.com Thu Mar 19 11:12: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 9CF223A698E for ; Thu, 19 Mar 2009 11:12:27 -0700 (PDT) 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_SE=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 rxQU+oliDhU8 for ; Thu, 19 Mar 2009 11:12:26 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8A6E43A695C for ; Thu, 19 Mar 2009 11:12:26 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EA41421415; Thu, 19 Mar 2009 19:13:10 +0100 (CET) X-AuditID: c1b4fb3e-abf91bb000007f6c-8d-49c28b364b37 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C52022112F; Thu, 19 Mar 2009 19:13:10 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 19:13:10 +0100 Received: from [153.88.52.180] ([153.88.52.180]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 19:13:09 +0100 Message-ID: <49C28B34.8070400@ericsson.com> Date: Thu, 19 Mar 2009 19:13:08 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Fred Baker References: <20090222012031.23ABE3A6781@core3.amsl.com> <7F1100A2-0EA4-403D-9329-06BA2CC6EAE5@cisco.com> In-Reply-To: <7F1100A2-0EA4-403D-9329-06BA2CC6EAE5@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2009 18:13:09.0841 (UTC) FILETIME=[5C0D7C10:01C9A8BE] X-Brightmail-Tracker: AAAAAA== Cc: "behave@ietf.org WG" Subject: [BEHAVE] Address questions on draft-baker-behave-v4v6-framework-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: Thu, 19 Mar 2009 18:12:27 -0000 Hi, I read this draft and the other translation drafts in BEHAVE. In regards to the framework, I ended up with one big question around addresses when using a stateless translator. -------- -------- // IPv4 \\ // IPv6 \\ / Domain \ / Domain \ / +----+ +--+ \ | |XLAT| |S3| | Sn: Servers | +--+ +----+ +--+ | Hn: Clients | |S1| +----+ | | +--+ |DNS | +--+ | XLAT: translator \ +--+ +----+ |H3| / DNS: DNS Server \ |H1| / \ +--+ / \ +--+ / \ / / \ / \ / +----+ \ | +--+ |XLAT| +--+ | | |S2| +----+ |S4| | | +--+ +----+ +--+ | | +--+ |DNS | +--+ | \ |H2| +----+ |H4| / \ +--+ / \ +--+ / \\ // \\ // -------- -------- In the above example if H3 and S1 is communicating and the translator is stateless. I do become uncertain about the address and thus resulting routing that is used for the S1->XLAT->H3 in the XLAT -> H3 step. I have the impression that H3 will have to been assigned a IPv4 related IPv6 address that the XLAT will know that the IPv4 pool address is related to a particular IPv6 address assigned to H3. Is this understanding correct? When we come to related addresses isn't this actually state? Either the translator has state that says IPv4 address X <-> IPv6 address Y' where Y' is H3's address. Alternatively it seems possible to use an address that the XLAT knows how to do automatic translate to an IPv6. A Mapped IPv6 with another prefix that routes from the XLAT to H3 if H3 has been assigned the specific mapped address. But I guess that then the state ends up in the routing state of the IPv6 domain. So stateless is only in the meaning that you don't need to track sessions state. You need some address state it appears to me somewhere. Are it at all practical to have it somewhere else than in the XLAT function? I think this part could be better clarified in the document. Mvh Magnus Westerlund As individual contributor From fred@cisco.com Thu Mar 19 11:39: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 5AAD33A6873 for ; Thu, 19 Mar 2009 11:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p++zR0JPzI5t for ; Thu, 19 Mar 2009 11:39:20 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F096E3A688A for ; Thu, 19 Mar 2009 11:39:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,389,1233532800"; d="scan'208";a="270498954" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Mar 2009 18:40:05 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2JIe5sp013374; Thu, 19 Mar 2009 11:40:05 -0700 Received: from nmtg-road1-4503.cisco.com (sjc-vpn6-847.cisco.com [10.21.123.79]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2JIe5fI024179; Thu, 19 Mar 2009 18:40:05 GMT Message-Id: <5BCCA3CB-D121-41D7-B556-41E407A9096E@cisco.com> From: Fred Baker To: Magnus Westerlund In-Reply-To: <49C28B34.8070400@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Mar 2009 11:40:05 -0700 References: <20090222012031.23ABE3A6781@core3.amsl.com> <7F1100A2-0EA4-403D-9329-06BA2CC6EAE5@cisco.com> <49C28B34.8070400@ericsson.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5016; t=1237488005; x=1238352005; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Address=20questions=20on=20draft-baker- behave-v4v6-framework-01 |Sender:=20; bh=8SN5lH42/L04sb40t/PPeq1A/nQ+A+tpgIvJe2ckIIw=; b=Ff4mc4+27/W+YA+dNQ5Jd78Ykm0A4CCd8/cHE3z8QJ6KtpcuT8ZjwhlltV yy0ZhqXHbMBpB8wFPxEBBtQIM3noeJxuEyyh0eree+VHR4tg4S/oK/Nei/IA Fcah61c/RT; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] Address questions on draft-baker-behave-v4v6-framework-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: Thu, 19 Mar 2009 18:39:21 -0000 On Mar 19, 2009, at 11:13 AM, Magnus Westerlund wrote: > Hi, > > I read this draft and the other translation drafts in BEHAVE. In > regards > to the framework, I ended up with one big question around addresses > when > using a stateless translator. > > > -------- -------- > // IPv4 \\ // IPv6 \\ > / Domain \ / Domain \ > / +----+ +--+ \ > | |XLAT| |S3| | Sn: Servers > | +--+ +----+ +--+ | Hn: Clients > | |S1| +----+ | > | +--+ |DNS | +--+ | XLAT: translator > \ +--+ +----+ |H3| / DNS: DNS Server > \ |H1| / \ +--+ / > \ +--+ / \ / > / \ / \ > / +----+ \ > | +--+ |XLAT| +--+ | > | |S2| +----+ |S4| | > | +--+ +----+ +--+ | > | +--+ |DNS | +--+ | > \ |H2| +----+ |H4| / > \ +--+ / \ +--+ / > \\ // \\ // > -------- -------- > > In the above example if H3 and S1 is communicating and the > translator is > stateless. I do become uncertain about the address and thus resulting > routing that is used for the S1->XLAT->H3 in the XLAT -> H3 step. That depends, of course, in part on how this is deployed. If the translators are using different prefixes to embed the IPv4 address into, routing, in both directions, is very specifically through the translator whose prefix one is using. If the translators are using the same prefix, routing could just as easily be asymmetric - S1->H3 goes through one translator (or is load-shared across both of them) and H3- >S1 goes through the other (or is load-shared). That is an important consideration when it comes to stateful translation as is proposed for general IPv6 clients reaching IPv4 servers. The destination address is the same format - IPv4 embedded in IPv6 - but the source address is a generic IPv6 address, which means that the stateful translator will have (much like NAT4/4) session state that overloads an IPv4 address with data from many IPv6 sources, and disambiguates that using the source port. I won't say that it can't load-share, but we don't plan to propose the necessary state management protocols. > I have the impression that H3 will have to been assigned a IPv4 > related > IPv6 address that the XLAT will know that the IPv4 pool address is > related to a particular IPv6 address assigned to H3. Is this > understanding correct? In this context, which is to say "stateless translation", yes, H3 will have an address that embeds an IPv4 address inside some IPv6 prefix. BTW, this is exactly the same behavior as SIIT; we're just using a different prefix. > When we come to related addresses isn't this actually state? Either > the > translator has state that says IPv4 address X <-> IPv6 address Y' > where > Y' is H3's address. Alternatively it seems possible to use an address > that the XLAT knows how to do automatic translate to an IPv6. A Mapped > IPv6 with another prefix that routes from the XLAT to H3 if H3 has > been > assigned the specific mapped address. But I guess that then the state > ends up in the routing state of the IPv6 domain. > So stateless is only in the meaning that you don't need to track > sessions state. You need some address state it appears to me > somewhere. > Are it at all practical to have it somewhere else than in the XLAT > function? > > I think this part could be better clarified in the document. Maybe you could suggest text. The reference to "state" is a reference to dynamic state maintained in the translator. In the words of draft-baker-behave-v4v6- framework-02.txt: State: "State" refers to dynamic information that is stored in a network element. For example, if two systems are connected by a TCP connection, each stores information about the connection, which is called "connection state". In this context, the term refers to dynamic correlations between IP addresses on either side of a translator, or {IP Address, Transport type, transport port number} tuples on either side of the translator. In the stateful mode, which connects a system using a generic IPv6 address with an IPv4 system, as I said above the translator will be forced to maintain dynamic state. In the stateless mode, there is no such state maintained by the translator - there is an algorithmic relationship between the IPv4 address, the prefix assigned by the operator, and the resulting IPv6 address. From magnus.westerlund@ericsson.com Thu Mar 19 12:00: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 4BD6F3A69A9 for ; Thu, 19 Mar 2009 12:00:27 -0700 (PDT) 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_SE=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 fAgjJbt3TQmh for ; Thu, 19 Mar 2009 12:00:26 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 662383A6CBA for ; Thu, 19 Mar 2009 12:00:13 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D445421454; Thu, 19 Mar 2009 20:00:57 +0100 (CET) X-AuditID: c1b4fb3e-aef97bb000007f6c-23-49c29669a118 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AF48A20240; Thu, 19 Mar 2009 20:00:57 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 20:00:56 +0100 Received: from [153.88.52.180] ([153.88.52.180]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 20:00:55 +0100 Message-ID: <49C2965F.1020700@ericsson.com> Date: Thu, 19 Mar 2009 20:00:47 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Fred Baker References: <20090222012031.23ABE3A6781@core3.amsl.com> <7F1100A2-0EA4-403D-9329-06BA2CC6EAE5@cisco.com> <49C28B34.8070400@ericsson.com> <5BCCA3CB-D121-41D7-B556-41E407A9096E@cisco.com> In-Reply-To: <5BCCA3CB-D121-41D7-B556-41E407A9096E@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Mar 2009 19:00:55.0720 (UTC) FILETIME=[083FEA80:01C9A8C5] X-Brightmail-Tracker: AAAAAA== Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] Address questions on draft-baker-behave-v4v6-framework-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: Thu, 19 Mar 2009 19:00:27 -0000 Fred Baker skrev: > > On Mar 19, 2009, at 11:13 AM, Magnus Westerlund wrote: > >> Hi, >> >> I read this draft and the other translation drafts in BEHAVE. In regards >> to the framework, I ended up with one big question around addresses when >> using a stateless translator. >> >> >> -------- -------- >> // IPv4 \\ // IPv6 \\ >> / Domain \ / Domain \ >> / +----+ +--+ \ >> | |XLAT| |S3| | Sn: Servers >> | +--+ +----+ +--+ | Hn: Clients >> | |S1| +----+ | >> | +--+ |DNS | +--+ | XLAT: translator >> \ +--+ +----+ |H3| / DNS: DNS Server >> \ |H1| / \ +--+ / >> \ +--+ / \ / >> / \ / \ >> / +----+ \ >> | +--+ |XLAT| +--+ | >> | |S2| +----+ |S4| | >> | +--+ +----+ +--+ | >> | +--+ |DNS | +--+ | >> \ |H2| +----+ |H4| / >> \ +--+ / \ +--+ / >> \\ // \\ // >> -------- -------- >> >> In the above example if H3 and S1 is communicating and the translator is >> stateless. I do become uncertain about the address and thus resulting >> routing that is used for the S1->XLAT->H3 in the XLAT -> H3 step. > > That depends, of course, in part on how this is deployed. If the > translators are using different prefixes to embed the IPv4 address into, > routing, in both directions, is very specifically through the translator > whose prefix one is using. If the translators are using the same prefix, > routing could just as easily be asymmetric - S1->H3 goes through one > translator (or is load-shared across both of them) and H3->S1 goes > through the other (or is load-shared). > > That is an important consideration when it comes to stateful translation > as is proposed for general IPv6 clients reaching IPv4 servers. The > destination address is the same format - IPv4 embedded in IPv6 - but the > source address is a generic IPv6 address, which means that the stateful > translator will have (much like NAT4/4) session state that overloads an > IPv4 address with data from many IPv6 sources, and disambiguates that > using the source port. I won't say that it can't load-share, but we > don't plan to propose the necessary state management protocols. > >> I have the impression that H3 will have to been assigned a IPv4 related >> IPv6 address that the XLAT will know that the IPv4 pool address is >> related to a particular IPv6 address assigned to H3. Is this >> understanding correct? > > In this context, which is to say "stateless translation", yes, H3 will > have an address that embeds an IPv4 address inside some IPv6 prefix. > BTW, this is exactly the same behavior as SIIT; we're just using a > different prefix. > >> When we come to related addresses isn't this actually state? Either the >> translator has state that says IPv4 address X <-> IPv6 address Y' where >> Y' is H3's address. Alternatively it seems possible to use an address >> that the XLAT knows how to do automatic translate to an IPv6. A Mapped >> IPv6 with another prefix that routes from the XLAT to H3 if H3 has been >> assigned the specific mapped address. But I guess that then the state >> ends up in the routing state of the IPv6 domain. > >> So stateless is only in the meaning that you don't need to track >> sessions state. You need some address state it appears to me somewhere. >> Are it at all practical to have it somewhere else than in the XLAT >> function? >> >> I think this part could be better clarified in the document. > > Maybe you could suggest text. Maybe, but actually on part of my confusion was around the IPv6 address used in the IPv6 domain and how you make the traffic going from the translator to the intended host. > > The reference to "state" is a reference to dynamic state maintained in > the translator. In the words of draft-baker-behave-v4v6-framework-02.txt: > > State: "State" refers to dynamic information that is stored in a > network element. For example, if two systems are connected by a > TCP connection, each stores information about the connection, > which is called "connection state". In this context, the term > refers to dynamic correlations between IP addresses on either side > of a translator, or {IP Address, Transport type, transport port > number} tuples on either side of the translator. > > In the stateful mode, which connects a system using a generic IPv6 > address with an IPv4 system, as I said above the translator will be > forced to maintain dynamic state. In the stateless mode, there is no > such state maintained by the translator - there is an algorithmic > relationship between the IPv4 address, the prefix assigned by the > operator, and the resulting IPv6 address. When rereading: Stateless Translation: A translation algorithm that is not "stateful" is "stateless". It may require configuration of a static translation table, or may derive its needed information algorithmically from the messages it is translating. I do see that it mention the static translation table. I think this would be clear if there was discussion more about the address and related routing in the IPv6 domain to get things back. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fred@cisco.com Thu Mar 19 13:41: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 A49A128C181 for ; Thu, 19 Mar 2009 13:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu47GJi7L37g for ; Thu, 19 Mar 2009 13:41:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C149B28C176 for ; Thu, 19 Mar 2009 13:41:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,391,1233532800"; d="scan'208";a="270573817" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Mar 2009 20:42:00 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2JKg0pA024837; Thu, 19 Mar 2009 13:42:00 -0700 Received: from nmtg-road1-4503.cisco.com ([10.21.73.60]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n2JKg0ht021595; Thu, 19 Mar 2009 20:42:00 GMT Message-Id: From: Fred Baker To: Magnus Westerlund In-Reply-To: <49C2965F.1020700@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Mar 2009 13:41:59 -0700 References: <20090222012031.23ABE3A6781@core3.amsl.com> <7F1100A2-0EA4-403D-9329-06BA2CC6EAE5@cisco.com> <49C28B34.8070400@ericsson.com> <5BCCA3CB-D121-41D7-B556-41E407A9096E@cisco.com> <49C2965F.1020700@ericsson.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=610; t=1237495320; x=1238359320; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Address=20questions=20on=20draft-baker- behave-v4v6-framework-01 |Sender:=20; bh=3hVxqOpBwxzuDTV0GTB77lw9TtFXxjFoQCCcN0sHd9M=; b=n/f06aVlLz2AdotBkw9vhmbBqK5EkmXwqEqHGuKX791otClBUAah2jCt4y Ihf8OyVmfNL8NXZDOsFVFm9fJJkVuPEkwRd46F3uO9oGgjKCggAxeZavzSrw 51afF8m/X5; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] Address questions on draft-baker-behave-v4v6-framework-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: Thu, 19 Mar 2009 20:41:15 -0000 On Mar 19, 2009, at 12:00 PM, Magnus Westerlund wrote: > Maybe, but actually on part of my confusion was around the IPv6 > address > used in the IPv6 domain and how you make the traffic going from the > translator to the intended host. Let me ask you this: when you have an SMB behind a NAT and a hugely complex internal network, and you assign an IPv4 address to an IPv4 host, how do you get the traffic from the NAT to the host? Hint: folks who answer such questions regularly are often familiar with acronyms like "OSPF", "IS-IS", "BGP", and "RIP". The same is true in IPv6. From magnus.westerlund@ericsson.com Thu Mar 19 14:12: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 780013A6AD4 for ; Thu, 19 Mar 2009 14:12:47 -0700 (PDT) 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_SE=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 0aNaHDkEqk7s for ; Thu, 19 Mar 2009 14:12:46 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C26393A69E0 for ; Thu, 19 Mar 2009 14:12:45 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C410212ED; Thu, 19 Mar 2009 22:12:59 +0100 (CET) X-AuditID: c1b4fb3c-ab483bb000004af0-e7-49c2b55ba305 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 737A6212F9; Thu, 19 Mar 2009 22:12:59 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 22:12:59 +0100 Received: from [153.88.52.180] ([153.88.52.180]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 22:12:58 +0100 Message-ID: <49C2B555.5040402@ericsson.com> Date: Thu, 19 Mar 2009 22:12:53 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Fred Baker References: <20090222012031.23ABE3A6781@core3.amsl.com> <7F1100A2-0EA4-403D-9329-06BA2CC6EAE5@cisco.com> <49C28B34.8070400@ericsson.com> <5BCCA3CB-D121-41D7-B556-41E407A9096E@cisco.com> <49C2965F.1020700@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Mar 2009 21:12:58.0870 (UTC) FILETIME=[7AD0A960:01C9A8D7] X-Brightmail-Tracker: AAAAAA== Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] Address questions on draft-baker-behave-v4v6-framework-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: Thu, 19 Mar 2009 21:12:47 -0000 Fred Baker skrev: > > On Mar 19, 2009, at 12:00 PM, Magnus Westerlund wrote: > >> Maybe, but actually on part of my confusion was around the IPv6 address >> used in the IPv6 domain and how you make the traffic going from the >> translator to the intended host. > > Let me ask you this: > > when you have an SMB behind a NAT and a hugely complex internal network, > and you assign an IPv4 address to an IPv4 host, how do you get the > traffic from the NAT to the host? > > Hint: folks who answer such questions regularly are often familiar with > acronyms like "OSPF", "IS-IS", "BGP", and "RIP". > > The same is true in IPv6. I was not asking for an explanation of routing, but I am missing any discussion of the address issue in the framework document. Do also remember that some people that are going to reading this are coming from the higher layers in the stack and not the lower ones. To me it seems to be several choices based on what type of addresses you are using. They are also directly affecting the technical choice or at least description of the solution. You are spending a reasonable amount of space to discuss the embedded addresses in the way of going from a v6 host to the translator, but not about the other direction. Am I completely wrong in that the choices for stateless are: 1. Put a table in the XLAT and use any IPv6 address for the host that you want to map a IPv4 XLAT pool address. 2. Use algorithmic mapping of the IPv4 pool address into a specific prefix and that seem to be possible to in several ways a. mapped address b. IPv4 related So don't you think there is reason to have some discussion in the document about this? Cheers Magnus Westerlund (as individual contributor) IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dwing@cisco.com Thu Mar 19 15: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 2D7C13A6BBE for ; Thu, 19 Mar 2009 15:03:56 -0700 (PDT) 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 cVrx1hNoZbvO for ; Thu, 19 Mar 2009 15:03:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 43D8B3A6BBD for ; Thu, 19 Mar 2009 15:03:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,391,1233532800"; d="scan'208";a="270621919" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Mar 2009 22:04:37 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2JM4ahg030022; Thu, 19 Mar 2009 15:04:36 -0700 Received: from dwingwxp01 (sjc-vpn5-1074.cisco.com [10.21.92.50]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2JM4aGb005466; Thu, 19 Mar 2009 22:04:36 GMT From: "Dan Wing" To: "'Brian E Carpenter'" References: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> <49B4CC0F.5040304@it.uc3m.es> <07f401c9a0f3$eff5cbd0$c2f0200a@cisco.com> <49B63DA3.4000707@it.uc3m.es> <49BF1C5D.6050900@gmail.com> <005101c9a6bd$fc167610$c2f0200a@cisco.com> <49C06E25.4020006@gmail.com> Date: Thu, 19 Mar 2009 15:04:36 -0700 Message-ID: <09a701c9a8de$b124b9f0$c2f0200a@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: Acmne93BCO0Z31dGT3qggC0XJPwCogBYqWmA In-Reply-To: <49C06E25.4020006@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=501; t=1237500276; x=1238364276; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20comment=20about=20draft-wing -behave-nat64-referrals-00.txt |Sender:=20; bh=CxSqWeb8/u5bKl0gbhmBafXld2J7rbmoyK5EM10o3jA=; b=zQYsVjhTII/J6cTEhesr0D3tvy0AahfHeIEy6gS/VBIi1bCsem/Pj2CuHg OwT6tKFmk19R5EIgoqoB7hApWztjDZUy/7EvxU5mB1HKCVMeygQ/t9E9PDpZ hFKkJRTd4P; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mohamed.boucadair@orange-ftgroup.com, behave@ietf.org Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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, 19 Mar 2009 22:03:56 -0000 > > Yes, this could form the basis for very useful guidance to > > application > > designers. ICE does something like this already, but > > abstracting its functions up several levels, as you propose, > > would be useful. > > > > Something like: "here is my IPv4 address, it goes through a > > translator so avoid using it if you can utilize my IPv6 address" > > and so on. > > Yes, but make the format extensible. Unofficial bar BOF in SF? Yes, that would be valuable. -d From fred@cisco.com Thu Mar 19 15: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 197833A6B0B for ; Thu, 19 Mar 2009 15:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpcdaEO227Ac for ; Thu, 19 Mar 2009 15:16:38 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3945D3A6902 for ; Thu, 19 Mar 2009 15:16:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,391,1233532800"; d="scan'208";a="158532072" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 19 Mar 2009 22:17:24 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2JMHOAM003284; Thu, 19 Mar 2009 15:17:24 -0700 Received: from nmtg-road1-4503.cisco.com ([10.21.73.60]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n2JMHObu006019; Thu, 19 Mar 2009 22:17:24 GMT Message-Id: From: Fred Baker To: Magnus Westerlund In-Reply-To: <49C2B555.5040402@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Mar 2009 15:17:23 -0700 References: <20090222012031.23ABE3A6781@core3.amsl.com> <7F1100A2-0EA4-403D-9329-06BA2CC6EAE5@cisco.com> <49C28B34.8070400@ericsson.com> <5BCCA3CB-D121-41D7-B556-41E407A9096E@cisco.com> <49C2965F.1020700@ericsson.com> <49C2B555.5040402@ericsson.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4105; t=1237501044; x=1238365044; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Address=20questions=20on=20draft-baker- behave-v4v6-framework-01 |Sender:=20; bh=hff+Yku5qOv/o8xvtpiwuawO8n0ZOmqRxIPQqT7+I14=; b=cQL05ze341hNovRp40r8/woC0oJOhoTsZDpevVwMHMfbnr2IsxuAbZTro4 4ZwUWr0rVQFLucT0yGvBg3NbMraRDHvAd7QV9t1nVfSMFVwPQAaIX3ycYUWN jOqjAmc7en07XHik0dUDdV/mg41/5VmOE2EfKQMZ7epmxRa7KIuJM=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] Address questions on draft-baker-behave-v4v6-framework-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: Thu, 19 Mar 2009 22:16:39 -0000 On Mar 19, 2009, at 2:12 PM, Magnus Westerlund wrote: > I was not asking for an explanation of routing, but I am missing any > discussion of the address issue in the framework document. Do also > remember that some people that are going to reading this are coming > from > the higher layers in the stack and not the lower ones. Perhaps. So I am looking at page 19, the page you copied Figure 7 from.: -------- -------- // IPv4 \\ // IPv6 \\ / Domain \ / Domain \ / +----+ +--+ \ | |XLAT| |S3| | Sn: Servers | +--+ +----+ +--+ | Hn: Clients | |S1| +----+ | | +--+ |DNS | +--+ | XLAT: translator \ +--+ +----+ |H3| / DNS: DNS Server \ |H1| / \ +--+ / \ +--+ / \ / / \ / \ / +----+ \ | +--+ |XLAT| +--+ | | |S2| +----+ |S4| | | +--+ +----+ +--+ | | +--+ |DNS | +--+ | \ |H2| +----+ |H4| / \ +--+ / \ +--+ / \\ // \\ // -------- -------- Figure 7: Service provider translation with multiple interchange points The immediately following bit of text reads: Since [RFC4291] specifies that routable IPv6 prefixes are 64 bits or shorter apart from host routes, one wishes to allocate each customer a /64 mapped to a few IPv4 addresses and a shorter prefix for his general use. The customer's CPE advertises the two prefixes into the IPv6 routing domain to attract relevant traffic. The translator advertises the mapped equivalent of an IPv4 default route into the IPv6 domain to attract all other traffic to it, for translation into the IPv4 routing domain. It also advertises an appropriate IPv4 prefix aggregating the mapped prefixes into the IPv4 domain to attract traffic intended for these customers. So, to put such an address in one's network, one configures it on the host (DHCP, manual configuration, whatever) and configures the host's router with a prefix that contains that host, or a static route to the host. The router injects the prefix or the static route into other routing in the manner this paragraph describes, and the packets get there. Were you looking for something else? > To me it seems to be several choices based on what type of addresses > you > are using. They are also directly affecting the technical choice or at > least description of the solution. You are spending a reasonable > amount > of space to discuss the embedded addresses in the way of going from > a v6 > host to the translator, but not about the other direction. > > Am I completely wrong in that the choices for stateless are: > > 1. Put a table in the XLAT and use any IPv6 address for the host that > you want to map a IPv4 XLAT pool address. If you want to replace a stateless model with a configured stateful model, yes, you could do that. Doing so would be different than what is being proposed here. > 2. Use algorithmic mapping of the IPv4 pool address into a specific > prefix and that seem to be possible to in several ways > a. mapped address > b. IPv4 related > > So don't you think there is reason to have some discussion in the > document about this? You see, I think there is. In fact, it jumps out of the page at me. So I need for you to help me see how you managed to confuse a "stateless" algorithm with a "configured stateful" algorithm, and how better to phrase this already-existing discussion so that you will understand it. Please suggest text. From xing@cernet.edu.cn Thu Mar 19 19:30: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 02EAA28C1B0 for ; Thu, 19 Mar 2009 19:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[AWL=-0.674, 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 NK9D7jERDx76 for ; Thu, 19 Mar 2009 19:30:11 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 0B48A28C1AE for ; Thu, 19 Mar 2009 19:30:09 -0700 (PDT) Received: from [127.0.0.1]([59.66.24.119]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm4e49c316f9; Fri, 20 Mar 2009 10:30:53 +0800 Message-ID: <49C2FFD4.6010307@cernet.edu.cn> Date: Fri, 20 Mar 2009 10:30:44 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fred Baker References: <20090222012031.23ABE3A6781@core3.amsl.com> <7F1100A2-0EA4-403D-9329-06BA2CC6EAE5@cisco.com> <49C28B34.8070400@ericsson.com> <5BCCA3CB-D121-41D7-B556-41E407A9096E@cisco.com> <49C2965F.1020700@ericsson.com> <49C2B555.5040402@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 07954kVB Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] Address questions on draft-baker-behave-v4v6-framework-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: Fri, 20 Mar 2009 02:30:12 -0000 > > On Mar 19, 2009, at 2:12 PM, Magnus Westerlund wrote: >> I was not asking for an explanation of routing, but I am missing any >> discussion of the address issue in the framework document. Do also >> remember that some people that are going to reading this are coming from >> the higher layers in the stack and not the lower ones. > Some additional information. (1) The address mapping and translation examples both for the stateless and stateful are discussed in the translation document. You may also see page 10 and page 17 in the presentation of http://www.ietf.org/proceedings/08nov/slides/behave-6.pdf (2) Concerning the routing issues, the Xlate follows the "more specific win" principle. (3) The reference of the stateless translation can be found in the draft http://tools.ietf.org/html/draft-xli-behave-ivi-01 xing > Perhaps. So I am looking at page 19, the page you copied Figure 7 from.: > > -------- -------- > // IPv4 \\ // IPv6 \\ > / Domain \ / Domain \ > / +----+ +--+ \ > | |XLAT| |S3| | Sn: Servers > | +--+ +----+ +--+ | Hn: Clients > | |S1| +----+ | > | +--+ |DNS | +--+ | XLAT: translator > \ +--+ +----+ |H3| / DNS: DNS Server > \ |H1| / \ +--+ / > \ +--+ / \ / > / \ / \ > / +----+ \ > | +--+ |XLAT| +--+ | > | |S2| +----+ |S4| | > | +--+ +----+ +--+ | > | +--+ |DNS | +--+ | > \ |H2| +----+ |H4| / > \ +--+ / \ +--+ / > \\ // \\ // > -------- -------- > > Figure 7: Service provider translation with multiple interchange > points > > The immediately following bit of text reads: > > Since [RFC4291] specifies that routable IPv6 prefixes are 64 bits or > shorter apart from host routes, one wishes to allocate each customer > a /64 mapped to a few IPv4 addresses and a shorter prefix for his > general use. The customer's CPE advertises the two prefixes into the > IPv6 routing domain to attract relevant traffic. The translator > advertises the mapped equivalent of an IPv4 default route into the > IPv6 domain to attract all other traffic to it, for translation into > the IPv4 routing domain. It also advertises an appropriate IPv4 > prefix aggregating the mapped prefixes into the IPv4 domain to > attract traffic intended for these customers. > > So, to put such an address in one's network, one configures it on the > host (DHCP, manual configuration, whatever) and configures the host's > router with a prefix that contains that host, or a static route to the > host. The router injects the prefix or the static route into other > routing in the manner this paragraph describes, and the packets get > there. > > Were you looking for something else? > >> To me it seems to be several choices based on what type of addresses you >> are using. They are also directly affecting the technical choice or at >> least description of the solution. You are spending a reasonable amount >> of space to discuss the embedded addresses in the way of going from a v6 >> host to the translator, but not about the other direction. >> >> Am I completely wrong in that the choices for stateless are: >> >> 1. Put a table in the XLAT and use any IPv6 address for the host that >> you want to map a IPv4 XLAT pool address. > > If you want to replace a stateless model with a configured stateful > model, yes, you could do that. Doing so would be different than what > is being proposed here. > >> 2. Use algorithmic mapping of the IPv4 pool address into a specific >> prefix and that seem to be possible to in several ways >> a. mapped address >> b. IPv4 related >> >> So don't you think there is reason to have some discussion in the >> document about this? > > You see, I think there is. In fact, it jumps out of the page at me. So > I need for you to help me see how you managed to confuse a "stateless" > algorithm with a "configured stateful" algorithm, and how better to > phrase this already-existing discussion so that you will understand it. > > Please suggest text. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From mohamed.boucadair@orange-ftgroup.com Fri Mar 20 01:20: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 40C1928C157 for ; Fri, 20 Mar 2009 01:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 Qu6IfzcF0clk for ; Fri, 20 Mar 2009 01:20:39 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 134F928C140 for ; Fri, 20 Mar 2009 01:20:38 -0700 (PDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 09:21:20 +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: Fri, 20 Mar 2009 09:21:20 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007DF0DF0@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] comment about draft-wing-behave-nat64-referrals-00.txt thread-index: Acmne93BCO0Z31dGT3qggC0XJPwCogBYqWmAABV8B3A= References: <49B3909F.2050309@it.uc3m.es> <6CF039C5B32037498B02251E11CDE6B007D4EEBF@ftrdmel3> <49B4CC0F.5040304@it.uc3m.es> <07f401c9a0f3$eff5cbd0$c2f0200a@cisco.com><49B63DA3.4000707@it.uc3m.es> <49BF1C5D.6050900@gmail.com><005101c9a6bd$fc167610$c2f0200a@cisco.com><49C06E25.4020006@gmail.com> <09a701c9a8de$b124b9f0$c2f0200a@cisco.com> From: To: , X-OriginalArrivalTime: 20 Mar 2009 08:21:20.0611 (UTC) FILETIME=[D950BB30:01C9A934] Cc: behave@ietf.org Subject: Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-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, 20 Mar 2009 08:20:40 -0000 Hi all, FYI, in the context of SIP services, the proposed semantic may be = supported by the atypes attribute as described in = http://tools.ietf.org/html/draft-boucadair-sipping-ipv6-atypes-01. In addition to the already defined values, the following ones may be = supported: - "here is my IPv4 address, it goes through a translator so avoid using = it if you can utilize my IPv6 address" (D. Wing) atypes=3D"ipv6, ipv4_via_nat46" - here is my IPv6 address, it goes through a translator so avoid using = it if you can utilize my IPv4 address atypes=3D"ipv4, ipv6_via_nat64" Cheers, Med =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de Dan Wing Envoy=E9 : jeudi 19 mars 2009 23:05 =C0 : 'Brian E Carpenter' Cc : BOUCADAIR Mohamed RD-CORE-CAE; behave@ietf.org Objet : Re: [BEHAVE] comment about = draft-wing-behave-nat64-referrals-00.txt > > Yes, this could form the basis for very useful guidance to=20 > > application designers. ICE does something like this already, but=20 > > abstracting its functions up several levels, as you propose, would=20 > > be useful. > >=20 > > Something like: "here is my IPv4 address, it goes through a=20 > > translator so avoid using it if you can utilize my IPv6 address" > > and so on. >=20 > Yes, but make the format extensible. Unofficial bar BOF in SF? Yes, that would be valuable. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From magnus.westerlund@ericsson.com Fri Mar 20 09: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 234973A6B15 for ; Fri, 20 Mar 2009 09:32:47 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=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 OH-vJ2czV5uK for ; Fri, 20 Mar 2009 09:32:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C70FC3A6B8C for ; Fri, 20 Mar 2009 09:32:45 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F0EA02025E; Fri, 20 Mar 2009 17:32:51 +0100 (CET) X-AuditID: c1b4fb3e-aa8a2bb00000053c-07-49c3c533dc8e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CB52421298; Fri, 20 Mar 2009 17:32:51 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 17:32:51 +0100 Received: from [153.88.48.224] ([153.88.48.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 17:32:49 +0100 Message-ID: <49C3C52F.4030005@ericsson.com> Date: Fri, 20 Mar 2009 09:32:47 -0700 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Fred Baker References: <20090222012031.23ABE3A6781@core3.amsl.com> <7F1100A2-0EA4-403D-9329-06BA2CC6EAE5@cisco.com> <49C28B34.8070400@ericsson.com> <5BCCA3CB-D121-41D7-B556-41E407A9096E@cisco.com> <49C2965F.1020700@ericsson.com> <49C2B555.5040402@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Mar 2009 16:32:49.0912 (UTC) FILETIME=[824EF780:01C9A979] X-Brightmail-Tracker: AAAAAA== Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] Address questions on draft-baker-behave-v4v6-framework-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: Fri, 20 Mar 2009 16:32:47 -0000 Fred Baker skrev: > > On Mar 19, 2009, at 2:12 PM, Magnus Westerlund wrote: >> I was not asking for an explanation of routing, but I am missing any >> discussion of the address issue in the framework document. Do also >> remember that some people that are going to reading this are coming from >> the higher layers in the stack and not the lower ones. > > Perhaps. So I am looking at page 19, the page you copied Figure 7 from.: > > -------- -------- > // IPv4 \\ // IPv6 \\ > / Domain \ / Domain \ > / +----+ +--+ \ > | |XLAT| |S3| | Sn: Servers > | +--+ +----+ +--+ | Hn: Clients > | |S1| +----+ | > | +--+ |DNS | +--+ | XLAT: translator > \ +--+ +----+ |H3| / DNS: DNS Server > \ |H1| / \ +--+ / > \ +--+ / \ / > / \ / \ > / +----+ \ > | +--+ |XLAT| +--+ | > | |S2| +----+ |S4| | > | +--+ +----+ +--+ | > | +--+ |DNS | +--+ | > \ |H2| +----+ |H4| / > \ +--+ / \ +--+ / > \\ // \\ // > -------- -------- > > Figure 7: Service provider translation with multiple interchange > points > > The immediately following bit of text reads: > > Since [RFC4291] specifies that routable IPv6 prefixes are 64 bits or > shorter apart from host routes, one wishes to allocate each customer > a /64 mapped to a few IPv4 addresses and a shorter prefix for his > general use. The customer's CPE advertises the two prefixes into the > IPv6 routing domain to attract relevant traffic. The translator > advertises the mapped equivalent of an IPv4 default route into the > IPv6 domain to attract all other traffic to it, for translation into > the IPv4 routing domain. It also advertises an appropriate IPv4 > prefix aggregating the mapped prefixes into the IPv4 domain to > attract traffic intended for these customers. > > So, to put such an address in one's network, one configures it on the > host (DHCP, manual configuration, whatever) and configures the host's > router with a prefix that contains that host, or a static route to the > host. The router injects the prefix or the static route into other > routing in the manner this paragraph describes, and the packets get there. > > Were you looking for something else? I was looking for the address discussion for the direction translator v6 domain host. I don't think that is clear in the SIIT document either, and as you will have different prefixes or type of addresses depending on direction I think this warrants as much discussion as the other direction. > >> To me it seems to be several choices based on what type of addresses you >> are using. They are also directly affecting the technical choice or at >> least description of the solution. You are spending a reasonable amount >> of space to discuss the embedded addresses in the way of going from a v6 >> host to the translator, but not about the other direction. >> >> Am I completely wrong in that the choices for stateless are: >> >> 1. Put a table in the XLAT and use any IPv6 address for the host that >> you want to map a IPv4 XLAT pool address. > > If you want to replace a stateless model with a configured stateful > model, yes, you could do that. Doing so would be different than what is > being proposed here. > >> 2. Use algorithmic mapping of the IPv4 pool address into a specific >> prefix and that seem to be possible to in several ways >> a. mapped address >> b. IPv4 related >> >> So don't you think there is reason to have some discussion in the >> document about this? > > You see, I think there is. In fact, it jumps out of the page at me. So I > need for you to help me see how you managed to confuse a "stateless" > algorithm with a "configured stateful" algorithm, and how better to > phrase this already-existing discussion so that you will understand it. I brought up the configured state solution because it wasn't clear which type of addressing you suggest one uses in the translator -> v6 host. This made my head spin around possible solutions. > > Please suggest text. > I think the information may be there but a bit dense unless you actually have the model in your head. Now that I re-read section 2.2 and these specific paragraphs I do understand the difference between them. For the representation of the IPv4 addresses in the IPv6 Internet in both stateless and stateful modes, the PREFIX is advertised in the IPv6 network by the translator, and packets addressed to this PRFIX will be routed to the translator. This PREFIX is configured for each translator, and DNS ALG. For the representation of the IPv6 addresses in the IPv4 Internet in the stateless mode, more specifics (defined as IVI6) inside this PREFIX are advertised in the ISP's IPv6 network by the CPE routers, and packets addressed to the more specifcs inside this PREFIX will be routed to the IPv6 end systems. This PREFIX is not used for the representation of the IPv6 addresses in the IPv4 Internet in the stateless mode. However, I am missing some introduction text that discusses the different prefixes for traffic to the translator and from the translator in the v6 domain. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Sat Mar 21 07:18: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 168373A69D6 for ; Sat, 21 Mar 2009 07:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=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 45YHjtnQz2Nz for ; Sat, 21 Mar 2009 07:18:12 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EF5243A680D for ; Sat, 21 Mar 2009 07:18:11 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 30C6B20A71; Sat, 21 Mar 2009 15:18:57 +0100 (CET) X-AuditID: c1b4fb3c-aeffbbb000004c86-14-49c4f74f5195 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BC74D20694; Sat, 21 Mar 2009 15:18:55 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 15:18:55 +0100 Received: from [153.88.44.119] ([153.88.44.119]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 15:18:54 +0100 Message-ID: <49C4F74D.9010006@ericsson.com> Date: Sat, 21 Mar 2009 07:18:53 -0700 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fred Baker , Behave WG , xing@cernet.edu.cn, congxiao@cernet.edu.cn X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Mar 2009 14:18:54.0912 (UTC) FILETIME=[F77D0400:01C9AA2F] X-Brightmail-Tracker: AAAAAA== Subject: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-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: Sat, 21 Mar 2009 14:18:13 -0000 Hi, I have reviewed the draft and have some comments. 1. Section 2.2, first paragraph: When it comes to zero UDP checksums we do have a proposal to allow them also for IPv6/UDP packets draft-eubanks-chimento-6man-00. As this is for things like Automatic Multicast Tunneling, I guess that we will see these over a 64 translator. As this changes the assumption about that zero checksum isn't useful somewhat, do we need to care? 2. Section 2.3: Should we include required support for the ICMP extension header (RFC 4884) in the document? 3. Section 3, Path MTU Discovery: I think Dave Thaler talked about the possibility for actually originating ICMP too big messages that indicate packet sizes that are less than 1280 bytes. I can understand that this is testing code that normally aren't executed and thus for interoperability the current proposed text is much safer. It could allow MTU discovery to work also for IPv4 paths with MTU lower than 1280. 4. Section 3.1: TOS field When it comes to the parts that are the diffserv field, there is the possibility that you like to remapp one set of code-points into another. Should there be some text recommending that such function is supported, or is it useless? 5. Section 3.1, and also 2.1: Next header / Protocol field translation. There are a few that are IPv6 specific shouldn't these be called out specific in this part? Cheers Magnus Westerlund (As individual contributor) IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fred@cisco.com Sat Mar 21 09:08: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 258AE3A6ABA for ; Sat, 21 Mar 2009 09:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHCbdq7Q1VLT for ; Sat, 21 Mar 2009 09:08:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 790063A6A4D for ; Sat, 21 Mar 2009 09:07:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,400,1233532800"; d="scan'208";a="271717049" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Mar 2009 16:08:43 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2LG8hJI012904; Sat, 21 Mar 2009 09:08:43 -0700 Received: from [192.168.1.100] (sjc-vpn4-278.cisco.com [10.21.81.22]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2LG8hjC008726; Sat, 21 Mar 2009 16:08:43 GMT Message-Id: <3BD3A7A3-0C86-4C17-A30F-C15A318AF4D9@cisco.com> From: Fred Baker To: Magnus Westerlund In-Reply-To: <49C4F74D.9010006@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Mar 2009 09:08:42 -0700 References: <49C4F74D.9010006@ericsson.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2094; t=1237651723; x=1238515723; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Comments=20on=20draft-baker-behave-v4v6 -translation-02 |Sender:=20; bh=e1qQlC+sejVi+G6MVe/Gj4ufQNPXqw8JjdBBohyBbMw=; b=cHINPU6OyT1B8zUvLwsYqA04m5qUuuwkafvl0LgVFiA1sWyGujWlooKwDS pBW99O0y/HiZOxWHTSOOASvOqhxghsaD4oekcOZIqqJ2vQF/zXs4ex7QN2/3 /ECPGpLEN5; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: xing@cernet.edu.cn, congxiao@cernet.edu.cn, Behave WG Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-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: Sat, 21 Mar 2009 16:08:09 -0000 Thanks On Mar 21, 2009, at 7:18 AM, Magnus Westerlund wrote: > Hi, > > I have reviewed the draft and have some comments. > > 1. Section 2.2, first paragraph: > > When it comes to zero UDP checksums we do have a proposal to allow =20 > them > also for IPv6/UDP packets draft-eubanks-chimento-6man-00. As this is =20= > for > things like Automatic Multicast Tunneling, I guess that we will see > these over a 64 translator. As this changes the assumption about that > zero checksum isn't useful somewhat, do we need to care? > > 2. Section 2.3: > > Should we include required support for the ICMP extension header (RFC > 4884) in the document? > > 3. Section 3, Path MTU Discovery: > > I think Dave Thaler talked about the possibility for actually > originating ICMP too big messages that indicate packet sizes that are > less than 1280 bytes. I can understand that this is testing code that > normally aren't executed and thus for interoperability the current > proposed text is much safer. It could allow MTU discovery to work also > for IPv4 paths with MTU lower than 1280. > > 4. Section 3.1: TOS field > > When it comes to the parts that are the diffserv field, there is the > possibility that you like to remapp one set of code-points into =20 > another. > Should there be some text recommending that such function is =20 > supported, > or is it useless? > > 5. Section 3.1, and also 2.1: > > Next header / Protocol field translation. There are a few that are =20 > IPv6 > specific shouldn't these be called out specific in this part? > > Cheers > > Magnus Westerlund > (As individual contributor) > > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From brian.e.carpenter@gmail.com Sat Mar 21 15:38: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 0B9EF3A6BA1 for ; Sat, 21 Mar 2009 15:38:37 -0700 (PDT) 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 4B0SuZMDnKoh for ; Sat, 21 Mar 2009 15:38:36 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 5E47A3A6B51 for ; Sat, 21 Mar 2009 15:38:36 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2037143wfg.31 for ; Sat, 21 Mar 2009 15:39:24 -0700 (PDT) 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=HST1JNHHfb842Z8xaL/Tj/jQiFYSuXMWVB1yOVFhDY4=; b=uFXVTTsR5rnngIc72D1lj3DFXOB5qqbkJOu0dfjzZmiw2yDBojiLAHwMf2jx/sXJfp KFQ6+6uWIkQtYQC24OxTAg5RGD4/LBT5vLx5KRmrZ+buvKjBYjNpGIY9Fc2WMLafdRBG avTRCFcP5fcBD/4+/uH/pA8VQ8MbvpThzqdyg= 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=TdBnmd/uTqC7sG8YzMpyHnXzL1GazC+Pgngt7g9O70HuSh32UEhDE6no05vjbh4uFo Wi+5xF4YndN6DwlYxr9tpSZ6hrh3o9YD/t4AQ+FT/cY1pzbXxdInUj58n3wzVYBgATCp K/WmYBKknT6TA7yOqK9Eba8jz5RlnsTcgJfjE= Received: by 10.143.13.17 with SMTP id q17mr2128738wfi.222.1237675164483; Sat, 21 Mar 2009 15:39:24 -0700 (PDT) Received: from ?130.129.64.245? (dhcp-40f5.meeting.ietf.org [130.129.64.245]) by mx.google.com with ESMTPS id 24sm7620260wfc.17.2009.03.21.15.39.23 (version=SSLv3 cipher=RC4-MD5); Sat, 21 Mar 2009 15:39:23 -0700 (PDT) Message-ID: <49C56C9A.1080602@gmail.com> Date: Sun, 22 Mar 2009 11:39:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Magnus Westerlund References: <49C4F74D.9010006@ericsson.com> In-Reply-To: <49C4F74D.9010006@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xing@cernet.edu.cn, congxiao@cernet.edu.cn, Behave WG , Fred Baker Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-02 - DSCP mapping X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 Mar 2009 22:38:37 -0000 > 4. Section 3.1: TOS field > > When it comes to the parts that are the diffserv field, there is the > possibility that you like to remapp one set of code-points into another. > Should there be some text recommending that such function is supported, > or is it useless? You can legitimately place a diffserv classifier/marker at pretty much any packet forwarding entity, but it's an optional (MAY) function, orthogonal to the forwarding. In this context, a translator is really just a strange forwarding engine. So I don't see any need to add to what RFC2474 & 2475 say. Brian From dwing@cisco.com Sat Mar 21 15:49: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 3DF853A69C0 for ; Sat, 21 Mar 2009 15:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.909 X-Spam-Level: X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, J_CHICKENPOX_92=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 4tpSiXzhaGYS for ; Sat, 21 Mar 2009 15:49:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3FC3F3A67E1 for ; Sat, 21 Mar 2009 15:49:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,401,1233532800"; d="scan'208";a="145234580" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 21 Mar 2009 22:50:35 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2LMoZaA006152; Sat, 21 Mar 2009 15:50:35 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2LMoZv8028280; Sat, 21 Mar 2009 22:50:35 GMT From: "Dan Wing" To: "'wangxuewei'" , References: <017601c9a719$377b7ab0$c2f0200a@cisco.com> <015801c9a871$8e723530$a80c6f0a@china.huawei.com> Date: Sat, 21 Mar 2009 15:50:35 -0700 Message-ID: <015701c9aa77$728a5bb0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <015801c9a871$8e723530$a80c6f0a@china.huawei.com> Thread-Index: AcmocZh+25CFYN5cQ5Sps0UqH9w+PgCBY+bw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3081; t=1237675835; x=1238539835; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Learning=20the=20IPv6=20Pref ix=20of=20a=20NAT64(draft-wing-behave-learn-prefix-01) |Sender:=20; bh=boOJeH5DuchvMzH7WiRBtbqOu+GGPkQO6sJvR1A4gOw=; b=A5aZOAgB9io+h3McT65oUZokla5tnbcs0Hm0JObuz+e53GqFDlGIt2Qak4 kctGTw/WELqQsFd+xetmQuiplcEavbw6pbQj88MW7ewnwdcdJgaWSR3BC8H2 wI3iF9Z5HY; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [BEHAVE] Learning the IPv6 Prefix of a NAT64(draft-wing-behave-learn-prefix-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, 21 Mar 2009 22:49:48 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of wangxuewei > Sent: Thursday, March 19, 2009 2:03 AM > To: Dan Wing; behave@ietf.org > Subject: Re: [BEHAVE] Learning the IPv6 Prefix of a > NAT64(draft-wing-behave-learn-prefix-01) > > hi, > > read through your draft draft-wing-behave-learn-prefix-01 > ,the IPv6 prefix and the prefix length can be learned using > DNS or DHCP. > > what i think is there exists another method of learning the > prefix and length by Router Advertisement (RA) message, for > the IPv6 host attaches to the same multicast link as AFT, AFT > can directly periodically advertise(or in response to valid > Router Solicitations) RA messages containing the /96 prefix > and length to the IPv6 host. That seems reasonable. > For the IPv6 host attaches to the different multicast link > with AFT, we can make AFT use dynamic routing protocol > (OSPF$B!"(BISIS etc) to announce the /96 prefix and length to edge > routers in the IPv6 domain, thus edge routers in the IPv6 > domain obtain the /96 prefix and length, they can > periodically advertise(or in response to valid Router > Solicitations) RA messages containing the /96 prefix and length. Today, at least, dynamic routing protocols aren't propagated to subscribers. Is that expected to change with IPv6, or would most subscribers use default routes as with today's IPv4? > how do you think this method ? -d > thanks > > > Xuewei Wang > > ----- Original Message ----- > From: Dan Wing > To: behave@ietf.org > Sent: Tuesday, March 17, 2009 11:58 PM > Subject: [BEHAVE] Learning the IPv6 Prefix of a > NAT64(draft-wing-behave-learn-prefix-01) > > Last week I submitted a new version of "Learning the > IPv6 Prefix of a NAT64", > > http://tools.ietf.org/html/draft-wing-behave-learn-prefix-01. > It describes > how an application can learn the prefix of its NAT64 > via DNS or via DHCP. The > DNS query would be sent to its DNS server, which is its > DNS64 if the service > provider is running a DNS64+NAT64. DHCP is > per-interface. Both the DNS and > DHCP methods allow the host to choose different NAT64s > for different purposes > (cost, performance, type of link). > > The significant change in this version is that a DNS > NAPTR query is sent, > rather than querying for a TXT record. > > I do not intend to present this document in San > Francisco. Rather, this > document exists to show it is possible for applications > to learn the NAT64 > prefix if they need to construct synthetic IPv6 > addresses themselves. So far, > only three applications have been identified which > might benefit from this > functionality: DNSSEC, BitTorrent, and SIP. > > Comments welcome. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From magnus.westerlund@ericsson.com Sat Mar 21 17:59: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 1DEA73A6848 for ; Sat, 21 Mar 2009 17:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_SE=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 nhHuVJtZQzAX for ; Sat, 21 Mar 2009 17:59:01 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 069883A68B0 for ; Sat, 21 Mar 2009 17:59:00 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E33DF2060F; Sun, 22 Mar 2009 01:59:47 +0100 (CET) X-AuditID: c1b4fb3c-ae7fabb000004c86-8e-49c58d830de0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9A741205E6; Sun, 22 Mar 2009 01:59:47 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Mar 2009 01:59:47 +0100 Received: from [153.88.52.157] ([153.88.52.157]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Mar 2009 01:59:46 +0100 Message-ID: <49C58D80.2010008@ericsson.com> Date: Sat, 21 Mar 2009 17:59:44 -0700 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Brian E Carpenter References: <49C4F74D.9010006@ericsson.com> <49C56C9A.1080602@gmail.com> In-Reply-To: <49C56C9A.1080602@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Mar 2009 00:59:46.0624 (UTC) FILETIME=[7E7EA400:01C9AA89] X-Brightmail-Tracker: AAAAAA== Cc: xing@cernet.edu.cn, congxiao@cernet.edu.cn, Behave WG , Fred Baker Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-02 - DSCP mapping X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2009 00:59:02 -0000 Brian E Carpenter skrev: >> 4. Section 3.1: TOS field >> >> When it comes to the parts that are the diffserv field, there is the >> possibility that you like to remapp one set of code-points into another. >> Should there be some text recommending that such function is supported, >> or is it useless? > > You can legitimately place a diffserv classifier/marker > at pretty much any packet forwarding entity, but it's > an optional (MAY) function, orthogonal to the forwarding. In this > context, a translator is really just a strange forwarding engine. > So I don't see any need to add to what RFC2474 & 2475 say. > Brian, maybe an informational reference to this behavior? The reason I think it at least should be mentioned is that a 64 translator do create a new boundary between potentially differently organized diffserv domains. Thus the need for a diffserv classifier/marker in the translator seems reasonable. It is not obvious that implementors will directly realize this. Thus at least a heads up about the possible need seems warranted. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From philip_matthews@magma.ca Sat Mar 21 18:27: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 9F9BF3A6B2F for ; Sat, 21 Mar 2009 18:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DATE_IN_PAST_06_12=1.069, 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 YA3dIU308hJb for ; Sat, 21 Mar 2009 18:27:20 -0700 (PDT) Received: from mail-01.primus.ca (mail11.primus.ca [216.254.141.178]) by core3.amsl.com (Postfix) with ESMTP id E10313A68B0 for ; Sat, 21 Mar 2009 18:27:19 -0700 (PDT) Received: from 209.220.168.194.ptr.us.xo.net ([209.220.168.194] helo=[10.71.0.126]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LlCTv-0004MN-1l; Sat, 21 Mar 2009 21:28:07 -0400 Message-Id: <6316ECDE-847F-4426-8FB1-7A5310740C05@magma.ca> From: Philip Matthews To: Heikki Vatiainen In-Reply-To: <49AEA3EF.9010104@archred.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 21 Mar 2009 12:27:06 -0400 References: <49AEA3EF.9010104@archred.com> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - 209.220.168.194.ptr.us.xo.net ([10.71.0.126]) [209.220.168.194] Cc: Behave WG Subject: Re: [BEHAVE] Small typo in draft-ietf-behave-turn-13 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2009 01:27:20 -0000 Thanks. I have put it on my list of things to fix in the next version. - Philip On Wed, 4-Mar-09, at 10:53 , Heikki Vatiainen wrote: > While going through the TURN draft, I noticed a small typo in the > "Detailed example" section, page 51. XOR-PEER-ADDRESS has been written > twice as XOR-PEER-ADDRSSS in one of the message sequence charts. > > -- > Heikki Vatiainen > Arch Red Oy, Tampere, Finland > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From philip_matthews@magma.ca Sat Mar 21 18:27: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 AD4103A6B73 for ; Sat, 21 Mar 2009 18:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 u84p-ZS-zuTA for ; Sat, 21 Mar 2009 18:27:21 -0700 (PDT) Received: from mail-01.primus.ca (mail11.primus.ca [216.254.141.178]) by core3.amsl.com (Postfix) with ESMTP id D97773A68B0 for ; Sat, 21 Mar 2009 18:27:20 -0700 (PDT) Received: from 209.220.168.194.ptr.us.xo.net ([209.220.168.194] helo=[10.71.0.126]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LlCTw-0004MN-2K; Sat, 21 Mar 2009 21:28:09 -0400 Message-Id: <02390E41-BF6F-4EC4-B0ED-0AB50C4DDAEF@magma.ca> From: Philip Matthews To: Christian Huitema In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1CB2853328@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 21 Mar 2009 12:54:11 -0400 References: <3975D16E-3CFB-40E0-B208-247A055A9BDB@magma.ca> <8EFB68EAE061884A8517F2A755E8B60A19DB1B29AC@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <8EFB68EAE061884A8517F2A755E8B60A1CB2853328@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - 209.220.168.194.ptr.us.xo.net ([10.71.0.126]) [209.220.168.194] Cc: Behave WG Subject: Re: [BEHAVE] TURN-13 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: Sun, 22 Mar 2009 01:27:21 -0000 Christian: My apologies for the slow reply. For some reason, this message did not reach my Inbox, and I found it only when looking through the BEHAVE list. Replies inline. - Philip On Sun, 1-Mar-09, at 21:14 , Christian Huitema wrote: > >> Yes. The rules of section 15 of RFC5389 must be followed: >> >> The value in the length field MUST contain the length of the Value >> part of the attribute, prior to padding, measured in bytes. Since >> STUN aligns attributes on 32-bit boundaries, attributes whose >> content >> is not a multiple of 4 bytes are padded with 1, 2, or 3 bytes of >> padding so that its value contains a multiple of 4 bytes. The >> padding bits are ignored, and may be any value. >> >> The last bit applies to the EVEN-PORT and DATA attributes of TURN. >> >> I suppose we could include a sentence in the spec saying this >> explicitly, even though the TURN spec does say (section 4): >> >> TURN is an extension to STUN. All TURN messages, with the >> exception >> of the ChannelData message, are STUN-formatted messages. All the >> base processing rules described in [RFC5389] apply to STUN- >> formatted >> messages. This means that all the message-forming and -processing >> descriptions in this document are implicitly prefixed with the >> rules >> of [RFC5389]. > > I found that part of the specification (and STUN) somewhat > confusing. For example, we get "even port" specified as: > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |R| RFFU | > +-+-+-+-+-+-+-+-+ > > While the 8 bit transport type (requested transport) is specified as: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Protocol | RFFU | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Do I understand correctly that the "attribute length" field shall be > set to 1 byte for Even-Port, and to 4 bytes for "requested- > transport"? The specification would be clearer, and would prevent > potential implementation mistakes, if the attribute descriptions > mentioned explicitly the value of the attribute length. > > > If that is so, what is the rationale for the encoding of the > requested transport? Why not simply specify: > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Protocol | > +-+-+-+-+-+-+-+-+ > > And let the T-L-V encoded do the padding? > _______________________________________________ The various approaches to this are historical. The REQUESTED- TRANSPORT attribute is one of the oldest attributes, though it has undergone a few changes, while EVEN-PORT is the most recent attribute added (replacing an older attribute which went through a number of changes). The different approaches reflect changing ideas on how to handle this padding issue. I agree that it would be nice if things were consistent. In fact, there are quite a few things that I would change in TURN if I had a free hand. However, these days my personal opinion is that the most important thing is to get the spec published and not spend more time polishing the spec. - Philip From brian.e.carpenter@gmail.com Sat Mar 21 19: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 5CBEE3A6AB8 for ; Sat, 21 Mar 2009 19:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 UK9-VLxORr9t for ; Sat, 21 Mar 2009 19:40:07 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 9DFB03A6A7E for ; Sat, 21 Mar 2009 19:40:07 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2130894wfg.31 for ; Sat, 21 Mar 2009 19:40:56 -0700 (PDT) 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=jqIY57J23GLGUv45uzTUrubnT5htUg2GlauBLFSIa94=; b=YTqtWK+BgE37OHAfxH31Y/cR2M9p7QCDFSgfQOMqLyVph4j31/kMEWfbWhKsQuaKoL H46WpfpWyCF3ccYFyVmez7S1r6omaaS2WGKNLYeR27aaYp/OtzpTpec4szT00Z2SM4uJ D7y60RCmwZRCHTb4jninJUFH1KRukEPJQJzHQ= 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=jZ5Aj56p3gnt+ndoVoDTVCipm1fLin2n1fIg9ui+FYYIfpWLxJT2MAbhnTSKWghMSL wwQ8xw5QSj5RDZymarLb161t61s2eaJlag2Oi1L3fHUmFjEcgfTuQopBRybBjy88MDGq LxobSiQHjlAP+3kOGET6yZvKI+cB2iEpVwLE8= Received: by 10.142.113.17 with SMTP id l17mr2189344wfc.293.1237689655973; Sat, 21 Mar 2009 19:40:55 -0700 (PDT) Received: from ?130.129.64.245? (dhcp-40f5.meeting.ietf.org [130.129.64.245]) by mx.google.com with ESMTPS id 22sm8111979wfi.21.2009.03.21.19.40.54 (version=SSLv3 cipher=RC4-MD5); Sat, 21 Mar 2009 19:40:55 -0700 (PDT) Message-ID: <49C5A535.104@gmail.com> Date: Sun, 22 Mar 2009 15:40:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Magnus Westerlund References: <49C4F74D.9010006@ericsson.com> <49C56C9A.1080602@gmail.com> <49C58D80.2010008@ericsson.com> In-Reply-To: <49C58D80.2010008@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xing@cernet.edu.cn, congxiao@cernet.edu.cn, Behave WG , Fred Baker Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-02 - DSCP mapping X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2009 02:40:08 -0000 On 2009-03-22 13:59, Magnus Westerlund wrote: > Brian E Carpenter skrev: >>> 4. Section 3.1: TOS field >>> >>> When it comes to the parts that are the diffserv field, there is the >>> possibility that you like to remapp one set of code-points into another. >>> Should there be some text recommending that such function is supported, >>> or is it useless? >> You can legitimately place a diffserv classifier/marker >> at pretty much any packet forwarding entity, but it's >> an optional (MAY) function, orthogonal to the forwarding. In this >> context, a translator is really just a strange forwarding engine. >> So I don't see any need to add to what RFC2474 & 2475 say. >> > > Brian, maybe an informational reference to this behavior? The reason I > think it at least should be mentioned is that a 64 translator do create > a new boundary between potentially differently organized diffserv > domains. Thus the need for a diffserv classifier/marker in the > translator seems reasonable. > > It is not obvious that implementors will directly realize this. Thus at > least a heads up about the possible need seems warranted. That works for me. Brian From xing@cernet.edu.cn Sun Mar 22 18:46: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 3B7A93A69E2 for ; Sun, 22 Mar 2009 18:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[AWL=-0.449, 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 sF8wstuv7umo for ; Sun, 22 Mar 2009 18:46:40 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 9DBDE3A6873 for ; Sun, 22 Mar 2009 18:46:38 -0700 (PDT) Received: from [127.0.0.1]([59.66.24.119]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm549c76819; Mon, 23 Mar 2009 09:47:26 +0800 Message-ID: <49C6EA28.9000201@cernet.edu.cn> Date: Mon, 23 Mar 2009 09:47:20 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Magnus Westerlund References: <20090222012031.23ABE3A6781@core3.amsl.com> <7F1100A2-0EA4-403D-9329-06BA2CC6EAE5@cisco.com> <49C28B34.8070400@ericsson.com> <5BCCA3CB-D121-41D7-B556-41E407A9096E@cisco.com> <49C2965F.1020700@ericsson.com> <49C2B555.5040402@ericsson.com> In-Reply-To: <49C2B555.5040402@ericsson.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: v0KQ9lVB Cc: "behave@ietf.org WG" , Fred Baker Subject: Re: [BEHAVE] Address questions on draft-baker-behave-v4v6-framework-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: Mon, 23 Mar 2009 01:46:41 -0000 Magnus Westerlund 写é“: > I was not asking for an explanation of routing, but I am missing any > discussion of the address issue in the framework document. Do also > remember that some people that are going to reading this are coming from > the higher layers in the stack and not the lower ones. > > To me it seems to be several choices based on what type of addresses you > are using. They are also directly affecting the technical choice or at > least description of the solution. You are spending a reasonable amount > of space to discuss the embedded addresses in the way of going from a v6 > host to the translator, but not about the other direction. > some additional information. 1. From a v6 host to the translator, we use same method both for stateless and stateful modes 1.1 In the stateless mode: embed global IPv4 addresses in an IPv6 network’s prefix 1.2 In the stateful mode: embed global IPv4 addresses in an IPv6 network’s prefix 2. From a v4 host to the translator, we use different methods for stateless ans stateful modes 2.1 In the stateless mode: embed a subset of the ISP’s IPv4 addresses in an IPv6 network’s prefix 2.2 In the stateful mode: use session initiated mapping table in the translator to do the translation. > Am I completely wrong in that the choices for stateless are: > > 1. Put a table in the XLAT and use any IPv6 address for the host that > you want to map a IPv4 XLAT pool address. > yes, in the stateful mode. > 2. Use algorithmic mapping of the IPv4 pool address into a specific > prefix and that seem to be possible to in several ways > a. mapped address > b. IPv4 related > > see above. > So don't you think there is reason to have some discussion in the > document about this? > we will add some discussion in the next version. thanks. xing > Cheers > > Magnus Westerlund > (as individual contributor) > > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From xing@cernet.edu.cn Sun Mar 22 18: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 81B1A3A6A0B for ; Sun, 22 Mar 2009 18:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.24 X-Spam-Level: X-Spam-Status: No, score=-0.24 tagged_above=-999 required=5 tests=[AWL=-0.337, 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 q6VZzVjxYfVO for ; Sun, 22 Mar 2009 18:55:11 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 209953A69EC for ; Sun, 22 Mar 2009 18:55:10 -0700 (PDT) Received: from [127.0.0.1]([59.66.24.119]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm1549c76a1a; Mon, 23 Mar 2009 09:55:59 +0800 Message-ID: <49C6EC2E.90308@cernet.edu.cn> Date: Mon, 23 Mar 2009 09:55:58 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Brian E Carpenter References: <49C4F74D.9010006@ericsson.com> <49C56C9A.1080602@gmail.com> <49C58D80.2010008@ericsson.com> <49C5A535.104@gmail.com> In-Reply-To: <49C5A535.104@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: vw1Y9lVB Cc: congxiao@cernet.edu.cn, Behave WG , Fred Baker Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-02 - DSCP mapping X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 01:55:12 -0000 Brian E Carpenter 写é“: Thanks! We will put it on the list of things to fix in the next version. xing > On 2009-03-22 13:59, Magnus Westerlund wrote: > >> Brian E Carpenter skrev: >> >>>> 4. Section 3.1: TOS field >>>> >>>> When it comes to the parts that are the diffserv field, there is the >>>> possibility that you like to remapp one set of code-points into another. >>>> Should there be some text recommending that such function is supported, >>>> or is it useless? >>>> >>> You can legitimately place a diffserv classifier/marker >>> at pretty much any packet forwarding entity, but it's >>> an optional (MAY) function, orthogonal to the forwarding. In this >>> context, a translator is really just a strange forwarding engine. >>> So I don't see any need to add to what RFC2474 & 2475 say. >>> >>> >> Brian, maybe an informational reference to this behavior? The reason I >> think it at least should be mentioned is that a 64 translator do create >> a new boundary between potentially differently organized diffserv >> domains. Thus the need for a diffserv classifier/marker in the >> translator seems reasonable. >> >> It is not obvious that implementors will directly realize this. Thus at >> least a heads up about the possible need seems warranted. >> > > That works for me. > > Brian > > > From fred@cisco.com Sun Mar 22 21:10: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 83F8F3A6923 for ; Sun, 22 Mar 2009 21:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELW6LF8CDtrD for ; Sun, 22 Mar 2009 21:10:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8911E3A6908 for ; Sun, 22 Mar 2009 21:10:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,405,1233532800"; d="scan'208";a="272241081" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 23 Mar 2009 04:11:37 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2N4Bb9j015112; Sun, 22 Mar 2009 21:11:37 -0700 Received: from dhcp-41cd.meeting.ietf.org (sjc-vpn7-1755.cisco.com [10.21.150.219]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n2N4BYN5015854; Mon, 23 Mar 2009 04:11:37 GMT Message-Id: <92AA0A79-2630-4223-8D6D-81E676D0A451@cisco.com> From: Fred Baker To: Brian E Carpenter In-Reply-To: <49C56C9A.1080602@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Mar 2009 21:11:34 -0700 References: <49C4F74D.9010006@ericsson.com> <49C56C9A.1080602@gmail.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1622; t=1237781497; x=1238645497; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[BEHAVE]=20Comments=20on=20draft-baker- behave-v4v6-translation-02=20-=20DSCP=20mapping |Sender:=20; bh=uAk03RiUSDZUnM4/JH3LKN5M7Bi3JtFLWBP3SSX6s3U=; b=ALyFZaIzF81icZpN0NmvLcO3splwS5T3efyk5g4WvOx8oiMgpHDEvQtf4m Hskinf1LZ+tGAKgfD6yzG50SPB6pOYJBHwyib0hfhZ5VlPiBWhtPvgf5UCYI JAFHBxaVCj; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: xing@cernet.edu.cn, congxiao@cernet.edu.cn, Behave WG Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-02 - DSCP mapping X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 04:10:48 -0000 On Mar 21, 2009, at 3:39 PM, Brian E Carpenter wrote: > >> 4. Section 3.1: TOS field >> >> When it comes to the parts that are the diffserv field, there is the >> possibility that you like to remapp one set of code-points into >> another. >> Should there be some text recommending that such function is >> supported, >> or is it useless? > > You can legitimately place a diffserv classifier/marker > at pretty much any packet forwarding entity, but it's > an optional (MAY) function, orthogonal to the forwarding. In this > context, a translator is really just a strange forwarding engine. > So I don't see any need to add to what RFC2474 & 2475 say. When it comes to this, although Xing Li has agreed to pick up the edit, I'm not so sure. Let me throw out my viewpoint. My viewpoint is, as you state, that DSCP modifications are generally done at the edge of a network, encoding something in the way that the next network will understand it. That is something RFC 2474/2475 are pretty clear about. Now, if the translator constitutes a network edge, the implied functionality applies. If it doesn't constitute an edge, this is unnecessary functionality. I guess I would ask why RFC 2460 (which was published within a few days of RFC 2474) didn't need to comment on the DSCP other than refer the reader to RFC 2474? I can see adding a reference to the relevant section of RFC 2474, but going into a great level of detail seems to me like a good way to get multiple, and as a result diverging, specifications. Diverging specifications are a Bad Thing... From yaozhishuai@gmail.com Mon Mar 23 00:40: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 4B2693A6801 for ; Mon, 23 Mar 2009 00:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 UPsIsPBZL2RD for ; Mon, 23 Mar 2009 00:40:48 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 024583A67A4 for ; Mon, 23 Mar 2009 00:40:46 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so430519eyf.31 for ; Mon, 23 Mar 2009 00:41:35 -0700 (PDT) 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=vNQZTQDcIHZAk8LyhMnzjdwFcnVPhjABhOFs4MJsUI0=; b=MhKmbNI4Qac3kftlSjX6G8QoMdxmLdu+yWx30ZBq7NV1d4DOBqsOP53U9TAX/ey1q4 aaGSh0HKcoaX0D9LVjp0FJfivEEU8pXKehzs480S3t84Yc7pXVZn+jDACkcH50/ceRCZ 51Gqk/keB4dUZomohEE+CQBqZi09SfvJ0uTvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=pjoi7GRXqZQkL44QaBxZWzyaLw4jjC1Pv9gPz/Br7Y7DOimD0xOli3gdT5Z8CXfrpA FkKPbTM4SWgfpam1fgH9ceCopPthbXj+bKn3WuXXrRITal6EAFpUlYSVpWkjDjV2q8fg eh3Q5GSXODCI+HMCLsVRL+1yLUBT0OFHlv5kE= MIME-Version: 1.0 Received: by 10.210.86.10 with SMTP id j10mr5199095ebb.30.1237794095766; Mon, 23 Mar 2009 00:41:35 -0700 (PDT) Date: Mon, 23 Mar 2009 09:41:35 +0200 Message-ID: From: Zhishuai Yao To: behave@ietf.org Content-Type: multipart/alternative; boundary=0015174c42ba621d1a0465c465cb Subject: [BEHAVE] Generating RTP packets through TURN server??? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 07:42:25 -0000 --0015174c42ba621d1a0465c465cb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello everyone, I am a university student. I have a school experiment which requirs to generate RTP packets which have to be fragmented by STUN. This means I have to build symmetric NATs and use STUN/TURN capable soft phone. And I also found a free TURN server NUMB. My problem is I failed to find any soft phone which supports TURN. Does any have experience on that. I am really appreciate someone could explain what kind of elements I shoud use to generate those RTP packets. Thanks!! Zhishuai Yao --0015174c42ba621d1a0465c465cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello everyone,

I am a university student. I have a school experimen= t which requirs to generate RTP packets which have to be fragmented by STUN= . This means I have to build symmetric NATs and use STUN/TURN capable soft = phone. And I also found a free TURN server NUMB.

My problem is I failed to find any soft phone which supports TURN. Does= any have experience on that. I am really appreciate someone could explain = what kind of elements I shoud use to generate those RTP packets. Thanks!!
Zhishuai Yao
--0015174c42ba621d1a0465c465cb-- From yaozhishuai@gmail.com Mon Mar 23 00: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 8DB2E3A67A4 for ; Mon, 23 Mar 2009 00:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599, HTML_IMAGE_ONLY_12=2.46, 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 w2NJ+HgPkK+F for ; Mon, 23 Mar 2009 00:49:10 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 7FC173A67C0 for ; Mon, 23 Mar 2009 00:49:09 -0700 (PDT) Received: by ewy9 with SMTP id 9so1492842ewy.37 for ; Mon, 23 Mar 2009 00:49:58 -0700 (PDT) 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=9JuL3/Uog6qBaZLZVarOK1mRNdRZALTmPY+vkCEXkM4=; b=GdqK91pnHnbGjEeOLVsG6taBo12Spwhqk9UVlB9fwXfD8wobjtxD0T38wVnmCq7Yze Q0OX8LUvhnikLvhEmPf6AvPWQjmNEA/vDFWETgNhikHF391d2dAX67vL2DnTUClr+tLH l280bFEnHsUi3h7Vf8sX6U4c5m0WrA7zKBLHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ERTMvm9ZiArGN1V8KVAlVnAvsndpn2+Cd9q79YTATh3xRpX8xJsfc5VIDsVMhs0h4o DvFYna2IClbYtrWMcIr2Ga7R38mDCbphJ9IIbfUOyEAweYkSqXE1vsFxANsfl/TMbOAW BRZeeFmKwKPooay25K8y0T4y9el8/ibEvKaVE= MIME-Version: 1.0 Received: by 10.210.18.8 with SMTP id 8mr2080041ebr.27.1237794598523; Mon, 23 Mar 2009 00:49:58 -0700 (PDT) Date: Mon, 23 Mar 2009 09:49:58 +0200 Message-ID: From: Zhishuai Yao To: behave@ietf.org Content-Type: multipart/alternative; boundary=0015174c43d85993fc0465c48366 Subject: [BEHAVE] Generating RTP packets through TURN server?? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 07:49:10 -0000 --0015174c43d85993fc0465c48366 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello everyone, I am a university student. I have a school experiment which requirs to generate RTP packets which have to be fragmented by STUN. This means I have to build symmetric NATs and use STUN/TURN capable soft phone. And I also found a free TURN server NUMB. My problem is I failed to find any soft phone which supports TURN. Does any have experience on that. I am really appreciate someone could explain what kind of elements I shoud use to generate those RTP packets. Thanks!! --0015174c43d85993fc0465c48366 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit




Hello everyone,

I am a university student. I have a school experiment which requirs to generate RTP packets which have to be fragmented by STUN. This means I have to build symmetric NATs and use STUN/TURN capable soft phone. And I also found a free TURN server NUMB.

My problem is I failed to find any soft phone which supports TURN. Does any have experience on that. I am really appreciate someone could explain what kind of elements I shoud use to generate those RTP packets. Thanks!! --0015174c43d85993fc0465c48366-- From xing@cernet.edu.cn Mon Mar 23 06:04: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 1A65D3A6AD3 for ; Mon, 23 Mar 2009 06:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.173 X-Spam-Level: X-Spam-Status: No, score=-0.173 tagged_above=-999 required=5 tests=[AWL=-0.270, 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 sWb4JfYVfUFO for ; Mon, 23 Mar 2009 06:04:40 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 6B1353A6A8F for ; Mon, 23 Mar 2009 06:04:38 -0700 (PDT) Received: from [127.0.0.1]([123.112.67.181]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jma49c80701; Mon, 23 Mar 2009 21:05:26 +0800 Message-ID: <49C7890D.8030009@cernet.edu.cn> Date: Mon, 23 Mar 2009 21:05:17 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fred Baker References: <49C4F74D.9010006@ericsson.com> <49C56C9A.1080602@gmail.com> <92AA0A79-2630-4223-8D6D-81E676D0A451@cisco.com> In-Reply-To: <92AA0A79-2630-4223-8D6D-81E676D0A451@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: vCSqjlVB Cc: Xing Li , congxiao@cernet.edu.cn, Behave WG Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-02 - DSCP mapping X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 13:04:41 -0000 Fred Baker 写é“: > > On Mar 21, 2009, at 3:39 PM, Brian E Carpenter wrote: > >> >>> 4. Section 3.1: TOS field >>> >>> When it comes to the parts that are the diffserv field, there is the >>> possibility that you like to remapp one set of code-points into >>> another. >>> Should there be some text recommending that such function is supported, >>> or is it useless? >> >> You can legitimately place a diffserv classifier/marker >> at pretty much any packet forwarding entity, but it's >> an optional (MAY) function, orthogonal to the forwarding. In this >> context, a translator is really just a strange forwarding engine. >> So I don't see any need to add to what RFC2474 & 2475 say. > > When it comes to this, although Xing Li has agreed to pick up the > edit, I'm not so sure. Let me throw out my viewpoint. I agree with Fred's comments. xing > > My viewpoint is, as you state, that DSCP modifications are generally > done at the edge of a network, encoding something in the way that the > next network will understand it. That is something RFC 2474/2475 are > pretty clear about. > > Now, if the translator constitutes a network edge, the implied > functionality applies. If it doesn't constitute an edge, this is > unnecessary functionality. I guess I would ask why RFC 2460 (which was > published within a few days of RFC 2474) didn't need to comment on the > DSCP other than refer the reader to RFC 2474? > > I can see adding a reference to the relevant section of RFC 2474, but > going into a great level of detail seems to me like a good way to get > multiple, and as a result diverging, specifications. Diverging > specifications are a Bad Thing... > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From slgodin@gmail.com Mon Mar 23 07:25: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 F3C053A6858 for ; Mon, 23 Mar 2009 07:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 mBvDLLTfp2Ti for ; Mon, 23 Mar 2009 07:25:13 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id EC9003A68C3 for ; Mon, 23 Mar 2009 07:25:10 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so1389377qwb.31 for ; Mon, 23 Mar 2009 07:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=RLYCR4YsSeJCGbnxsIam3JTdDz0zSt9d3EPWLywfhhk=; b=CQnc8/uQUw9HsyIbi3Ypygzh4eI46UG3tE/2hO2+qAecXGyW+ff5gnmf4OO/bJxMJe 89rQolqRTiVyP4SzY+QdRDqbwjV5oFRLtPjGppkxlNE+As3+CEBytUoCTQpfF1kTgsSs v0ihYVOg++P5j1eX/qtdkb1QkGxkAqU110ZfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=YDL51tKJncvtzz86mtu+ODLRZuXcu7qy28vSvVxGYhHcpTfN37Iiw5poL8mbcaB7Xo CYfdbeM0NBc1nGrvdRX15mo0sFl/5PsYAkOBvK0NhTzzSCS6X1hCWbR6Iyz+4Ein43nI FfcbReSSIAoBRBBf2USUdUFAxKV6KXD3uOUy4= MIME-Version: 1.0 Sender: slgodin@gmail.com Received: by 10.220.45.203 with SMTP id g11mr2429124vcf.70.1237818359488; Mon, 23 Mar 2009 07:25:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2009 10:25:58 -0400 X-Google-Sender-Auth: 180921584b0dcab3 Message-ID: <82d15bd90903230725o52ebea46k26426e93f51e4b18@mail.gmail.com> From: Scott Godin To: Zhishuai Yao Content-Type: multipart/alternative; boundary=0016364ecc229d2d460465ca0bb4 Cc: behave@ietf.org Subject: Re: [BEHAVE] Generating RTP packets through TURN server??? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 14:25:21 -0000 --0016364ecc229d2d460465ca0bb4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit You could take a look at the open source recon project. It has a text based test console (testUA) that emulates SIP phone / useragent with media capabilities. It has the ability to send RTP packets through a TURN server, and can open allocations over UDP/TCP or TLS. http://www.resiprocate.org/Recon_Overview You can also look at the reTurn project for a STUN/TURN server and client library. http://www.resiprocate.org/ReTurn_Overview Scott 2009/3/23 Zhishuai Yao > Hello everyone, > > I am a university student. I have a school experiment which requirs to > generate RTP packets which have to be fragmented by STUN. This means I have > to build symmetric NATs and use STUN/TURN capable soft phone. And I also > found a free TURN server NUMB. > > My problem is I failed to find any soft phone which supports TURN. Does any > have experience on that. I am really appreciate someone could explain what > kind of elements I shoud use to generate those RTP packets. Thanks!! > > Zhishuai Yao > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > --0016364ecc229d2d460465ca0bb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You could take a look at the open source recon project. =A0It has a text ba= sed test console (testUA) that emulates SIP phone / =A0useragent with media= capabilities. =A0It has the ability to send RTP packets through a TURN ser= ver, and can open allocations over UDP/TCP or TLS. =A0 =A0http://www.resiprocate.org/Recon_Overv= iew

You can also look at the reTurn project for a STUN/TURN serv= er and client library. =A0http://www.resiprocate.org/ReTurn_Overview

Scot= t

2009/3/23 Zhishuai Yao <yaozhishuai@gmail.com>= ;
Hello everyone,

I am a university student. I have a school experimen= t which requirs to generate RTP packets which have to be fragmented by STUN= . This means I have to build symmetric NATs and use STUN/TURN capable soft = phone. And I also found a free TURN server NUMB.

My problem is I failed to find any soft phone which supports TURN. Does= any have experience on that. I am really appreciate someone could explain = what kind of elements I shoud use to generate those RTP packets. Thanks!!
Zhishuai Yao

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


--0016364ecc229d2d460465ca0bb4-- From brian.e.carpenter@gmail.com Mon Mar 23 07:33: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 817A228C13D for ; Mon, 23 Mar 2009 07:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 rT8EWXozPBj4 for ; Mon, 23 Mar 2009 07:33:29 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 20BD43A67DD for ; Mon, 23 Mar 2009 07:33:28 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so3340830ywh.49 for ; Mon, 23 Mar 2009 07:34:18 -0700 (PDT) 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=kF0uxLy267K38TDET4wjnGEtjsTyz4OMdh+dVeTCBu4=; b=slP6j73cx737i5IkFlpami+Q8GcO6m+vfjpALh1fvFSU7/bOu8WiltQhPRPdlvaeYg goWcK/+8dqX5ZzZTuIWDtI2/EXBf6kcEBZKHG8ObMT7mnJuQoFHVwud3UHcwgN2Qshqg r/grK8Bof4SK/fA7ScQZWgHx66u6PR8xs8xBY= 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=F5B+4Znpx9zrbHIF43D9a3s9jOY2WgE6t85etYjn+IyoMNoDCldDiAM7kTDI/hBqR1 EriXvD/U9Or9mLyWu1uBfEH6YpuLXYkIUrON0yeYbdxVcFqhbbctmdiCTDsea05LNUC3 +LT2qDP3MLLcqy968KiBwsJIJaZpcpwM3IMdY= Received: by 10.143.18.21 with SMTP id v21mr2873508wfi.336.1237818857301; Mon, 23 Mar 2009 07:34:17 -0700 (PDT) Received: from ?130.129.64.245? (dhcp-40f5.meeting.ietf.org [130.129.64.245]) by mx.google.com with ESMTPS id 22sm11701621wfi.1.2009.03.23.07.34.15 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Mar 2009 07:34:16 -0700 (PDT) Message-ID: <49C79DDF.8070500@gmail.com> Date: Tue, 24 Mar 2009 03:34:07 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <49C4F74D.9010006@ericsson.com> <49C56C9A.1080602@gmail.com> <92AA0A79-2630-4223-8D6D-81E676D0A451@cisco.com> In-Reply-To: <92AA0A79-2630-4223-8D6D-81E676D0A451@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xing@cernet.edu.cn, congxiao@cernet.edu.cn, Behave WG Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-02 - DSCP mapping X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 14:33:30 -0000 Fred - let's wait for the revised text, since I don't see a difference between what you say and what Magnus said. I agree of course that there is no new normative text needed (as there wasn't for tunnels, which is why RFC2983 is Informative). Pretty much all that is needed is 'By the way, check out 2474/2475, because this could also be a diffserv domain boundary.' Brian On 2009-03-23 17:11, Fred Baker wrote: > > On Mar 21, 2009, at 3:39 PM, Brian E Carpenter wrote: > >> >>> 4. Section 3.1: TOS field >>> >>> When it comes to the parts that are the diffserv field, there is the >>> possibility that you like to remapp one set of code-points into another. >>> Should there be some text recommending that such function is supported, >>> or is it useless? >> >> You can legitimately place a diffserv classifier/marker >> at pretty much any packet forwarding entity, but it's >> an optional (MAY) function, orthogonal to the forwarding. In this >> context, a translator is really just a strange forwarding engine. >> So I don't see any need to add to what RFC2474 & 2475 say. > > When it comes to this, although Xing Li has agreed to pick up the edit, > I'm not so sure. Let me throw out my viewpoint. > > My viewpoint is, as you state, that DSCP modifications are generally > done at the edge of a network, encoding something in the way that the > next network will understand it. That is something RFC 2474/2475 are > pretty clear about. > > Now, if the translator constitutes a network edge, the implied > functionality applies. If it doesn't constitute an edge, this is > unnecessary functionality. I guess I would ask why RFC 2460 (which was > published within a few days of RFC 2474) didn't need to comment on the > DSCP other than refer the reader to RFC 2474? > > I can see adding a reference to the relevant section of RFC 2474, but > going into a great level of detail seems to me like a good way to get > multiple, and as a result diverging, specifications. Diverging > specifications are a Bad Thing... > From magnus.westerlund@ericsson.com Mon Mar 23 07:57: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 51F2528C13A for ; Mon, 23 Mar 2009 07:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_SE=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 gxBopZxU5J8P for ; Mon, 23 Mar 2009 07:57:26 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 3C56328C10A for ; Mon, 23 Mar 2009 07:57:26 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 26D2920F48; Mon, 23 Mar 2009 15:58:15 +0100 (CET) X-AuditID: c1b4fb3c-ae760bb000003f6e-a5-49c7a38702fe Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 08D3F20CDC; Mon, 23 Mar 2009 15:58:15 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 15:58:14 +0100 Received: from [153.88.44.200] ([153.88.44.200]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 15:58:13 +0100 Message-ID: <49C7A384.1010402@ericsson.com> Date: Mon, 23 Mar 2009 07:58:12 -0700 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fred Baker References: <49C4F74D.9010006@ericsson.com> <49C56C9A.1080602@gmail.com> <92AA0A79-2630-4223-8D6D-81E676D0A451@cisco.com> In-Reply-To: <92AA0A79-2630-4223-8D6D-81E676D0A451@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Mar 2009 14:58:13.0815 (UTC) FILETIME=[CA548C70:01C9ABC7] X-Brightmail-Tracker: AAAAAA== Cc: xing@cernet.edu.cn, congxiao@cernet.edu.cn, Behave WG Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-02 - DSCP mapping X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 14:57:27 -0000 Fred Baker skrev: > > On Mar 21, 2009, at 3:39 PM, Brian E Carpenter wrote: > >> >>> 4. Section 3.1: TOS field >>> >>> When it comes to the parts that are the diffserv field, there is the >>> possibility that you like to remapp one set of code-points into another. >>> Should there be some text recommending that such function is supported, >>> or is it useless? >> >> You can legitimately place a diffserv classifier/marker >> at pretty much any packet forwarding entity, but it's >> an optional (MAY) function, orthogonal to the forwarding. In this >> context, a translator is really just a strange forwarding engine. >> So I don't see any need to add to what RFC2474 & 2475 say. > > When it comes to this, although Xing Li has agreed to pick up the edit, > I'm not so sure. Let me throw out my viewpoint. > > My viewpoint is, as you state, that DSCP modifications are generally > done at the edge of a network, encoding something in the way that the > next network will understand it. That is something RFC 2474/2475 are > pretty clear about. Agreed, but can you assume that both IPv4 and IPv6 address domains are going to use the same DSCP codepoint plan? If they don't then you need to have the reclassifier independent if the translator is sitting on a edge or not. > > Now, if the translator constitutes a network edge, the implied > functionality applies. If it doesn't constitute an edge, this is > unnecessary functionality. I guess I would ask why RFC 2460 (which was > published within a few days of RFC 2474) didn't need to comment on the > DSCP other than refer the reader to RFC 2474? > > I can see adding a reference to the relevant section of RFC 2474, but > going into a great level of detail seems to me like a good way to get > multiple, and as a result diverging, specifications. Diverging > specifications are a Bad Thing... > I am fine with simply pointing out the potential need for a DSCP reclassifier in the translator. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fred@cisco.com Mon Mar 23 08:11: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 DE4963A6C38 for ; Mon, 23 Mar 2009 08:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24ISiIxnQYbr for ; Mon, 23 Mar 2009 08:11:58 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1748D3A6C37 for ; Mon, 23 Mar 2009 08:11:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,408,1233532800"; d="scan'208";a="272583616" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 23 Mar 2009 15:12:35 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2NFCZUh010809; Mon, 23 Mar 2009 08:12:35 -0700 Received: from dhcp-41cd.meeting.ietf.org (sjc-vpn2-1389.cisco.com [10.21.117.109]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n2NFCZbT005425; Mon, 23 Mar 2009 15:12:35 GMT Message-Id: <00165318-CC86-49F5-BBC6-7FFF4D1C12C2@cisco.com> From: Fred Baker To: Magnus Westerlund In-Reply-To: <49C7A384.1010402@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Mar 2009 08:12:35 -0700 References: <49C4F74D.9010006@ericsson.com> <49C56C9A.1080602@gmail.com> <92AA0A79-2630-4223-8D6D-81E676D0A451@cisco.com> <49C7A384.1010402@ericsson.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1083; t=1237821155; x=1238685155; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[BEHAVE]=20Comments=20on=20draft-baker- behave-v4v6-translation-02=20-=20DSCP=20mapping |Sender:=20; bh=a8lbTW/viTeF8XdkZVRE9cVeGbxxT2vy8ieB+xEWJyA=; b=Aj/fno8M3j3Q/ioF+TqxDrLTzavw/Lz+YmT4KQ5kt2l6CSoN/iva3kk7Ip fDY4bIq87Q851XUBr5NU2sLu7TBCdvcnUaaHKGCNaCWQBgI0/OxltxFiQEjm eYKlxX2TXg; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: xing@cernet.edu.cn, congxiao@cernet.edu.cn, Behave WG Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-02 - DSCP mapping X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 15:11:59 -0000 On Mar 23, 2009, at 7:58 AM, Magnus Westerlund wrote: >> My viewpoint is, as you state, that DSCP modifications are generally >> done at the edge of a network, encoding something in the way that the >> next network will understand it. That is something RFC 2474/2475 are >> pretty clear about. > > Agreed, but can you assume that both IPv4 and IPv6 address domains are > going to use the same DSCP codepoint plan? If they don't then you need > to have the reclassifier independent if the translator is sitting on a > edge or not. I don't see any reason to automatically assume one or the other. If the two domains are run by a common administration, I would be very surprised to see the administration have different sets of rules. If they are different administrations, they might very well have different services. The question isn't whether they run IPv4, IPv6, or IPv16 for that matter; the question is the administrative boundary. Which is what RFC 2474/2475 say and the reason that documents that focus on IP headers simply point to them. From magnus.westerlund@ericsson.com Mon Mar 23 08:43: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 0DD4528C14E for ; Mon, 23 Mar 2009 08:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_SE=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 YzyK3M2nzfT3 for ; Mon, 23 Mar 2009 08:43:18 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E25A328C14B for ; Mon, 23 Mar 2009 08:43:17 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E48FA211E1; Mon, 23 Mar 2009 16:44:06 +0100 (CET) X-AuditID: c1b4fb3e-ab7b4bb000006d6d-0b-49c7ae464287 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C1EE220515; Mon, 23 Mar 2009 16:44:06 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 16:44:06 +0100 Received: from [153.88.44.200] ([153.88.44.200]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 16:44:06 +0100 Message-ID: <49C7AE44.70404@ericsson.com> Date: Mon, 23 Mar 2009 08:44:04 -0700 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fred Baker References: <49C4F74D.9010006@ericsson.com> <49C56C9A.1080602@gmail.com> <92AA0A79-2630-4223-8D6D-81E676D0A451@cisco.com> <49C7A384.1010402@ericsson.com> <00165318-CC86-49F5-BBC6-7FFF4D1C12C2@cisco.com> In-Reply-To: <00165318-CC86-49F5-BBC6-7FFF4D1C12C2@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Mar 2009 15:44:06.0360 (UTC) FILETIME=[32F99580:01C9ABCE] X-Brightmail-Tracker: AAAAAA== Cc: xing@cernet.edu.cn, congxiao@cernet.edu.cn, Behave WG Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-02 - DSCP mapping X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 15:43:19 -0000 Fred Baker skrev: > > On Mar 23, 2009, at 7:58 AM, Magnus Westerlund wrote: > >>> My viewpoint is, as you state, that DSCP modifications are generally >>> done at the edge of a network, encoding something in the way that the >>> next network will understand it. That is something RFC 2474/2475 are >>> pretty clear about. >> >> Agreed, but can you assume that both IPv4 and IPv6 address domains are >> going to use the same DSCP codepoint plan? If they don't then you need >> to have the reclassifier independent if the translator is sitting on a >> edge or not. > > I don't see any reason to automatically assume one or the other. If the > two domains are run by a common administration, I would be very > surprised to see the administration have different sets of rules. If > they are different administrations, they might very well have different > services. The question isn't whether they run IPv4, IPv6, or IPv16 for > that matter; the question is the administrative boundary. Agreed, but the border can exist, that was my point. > > Which is what RFC 2474/2475 say and the reason that documents that focus > on IP headers simply point to them. > Also agreed! Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fred@cisco.com Mon Mar 23 13:06: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 292AB3A6C97 for ; Mon, 23 Mar 2009 13:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spkavRCz3U5c for ; Mon, 23 Mar 2009 13:06:19 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 216F83A6B32 for ; Mon, 23 Mar 2009 13:06:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,409,1233532800"; d="scan'208";a="145470944" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2009 20:07:09 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2NK793F006480; Mon, 23 Mar 2009 13:07:09 -0700 Received: from dhcp-41cd.meeting.ietf.org (sjc-vpn6-723.cisco.com [10.21.122.211]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2NK79sE021870; Mon, 23 Mar 2009 20:07:09 GMT Message-Id: <18F6D3DB-4436-4289-B245-3F174E0E675A@cisco.com> From: Fred Baker To: Magnus Westerlund In-Reply-To: <49C4F74D.9010006@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Mar 2009 13:07:09 -0700 References: <49C4F74D.9010006@ericsson.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5191; t=1237838829; x=1238702829; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Comments=20on=20draft-baker-behave-v4v6 -translation-02 |Sender:=20; bh=GWk1XXVJKiifzTMQSYrmYlLR4Zt8Qym0aZ63k85Lkh0=; b=fvKeEw1waGpKZMrHlvVXu/ZedDD4USzJMYqPaLNBQxw4Orqg+vtJ8cm4Tn jvgC0pnCUS6apixSAAufjc8kVTJgMhyN9FyCP3w1VfchH8bgB995Qn45XK1r vMM7iW/ustOaJWX0A0CgKXqOSle+nJsLZW97ULm/upUzqE6JQEFt8=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: xing@cernet.edu.cn, congxiao@cernet.edu.cn, Behave WG Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-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: Mon, 23 Mar 2009 20:06:20 -0000 On Mar 21, 2009, at 7:18 AM, Magnus Westerlund wrote: > Hi, > > I have reviewed the draft and have some comments. > > 1. Section 2.2, first paragraph: > > When it comes to zero UDP checksums we do have a proposal to allow =20 > them > also for IPv6/UDP packets draft-eubanks-chimento-6man-00. As this is =20= > for > things like Automatic Multicast Tunneling, I guess that we will see > these over a 64 translator. As this changes the assumption about that > zero checksum isn't useful somewhat, do we need to care? I see that as a question for 6man. In a translator, either we require =20= a checksum in UDP, or we don't, in my view. Please don't ask me to try =20= to determine whether the UDP message is using some specific protocol. =20= At least one viewpoint would suggest that RFC 2460's insistence on the =20= checksum was an unauthorized change to a protocol not under discussion. Question for you, here. Are you asking us to flag the fact that a UDP =20= datagram transiting from an IPv4 network to an IPv6 network may =20 require a checksum calculation if it is zeroed? Personally, I would =20 prefer to see that done on the host or not at all. Think in the =20 context of gigabit links. I would rather give the translator the =20 option of discarding the datagram and telling the administrator to =20 reconfigure his hosts. > 2. Section 2.3: > > Should we include required support for the ICMP extension header (RFC > 4884) in the document? Tell me: is there anything that makes a strong statement about the =20 implementation of RFC 4884 in other systems? It seems like the level =20 of requirement here would be the same as the level of requirement in =20 other systems. I might be willing to see it as a "SHOULD". =46rom my perspective (being = =20 one of the editors who worked with normative language prior to Scott's =20= RFC defining the terms), I use "MUST" when the failure to do something =20= breaks something, and I try to say what broke. I use SHOULD when it is =20= something I would like to require but don't think failure to implement =20= actually breaks anything. I use MAY when there are those who care but =20= I'm not one of them. If I say that the implementer MUST implement 4884, then I think I am =20 duty bound to detail a section telling him how, and I think I am also =20= bound to tell him what will break if he doesn't - and I think that is =20= "RFC 4884 functionality". So in my mind, "MUST" doesn't fit. If there =20= is no statement to the effect that folks SHOULD implement RFC 4884 in =20= other places this one is an odd first choice in upping the ante. I =20 could imagine simply pointing to the document and making no =20 requirement statement at all. Give me something solid to work from here? > 3. Section 3, Path MTU Discovery: > > I think Dave Thaler talked about the possibility for actually > originating ICMP too big messages that indicate packet sizes that are > less than 1280 bytes. I can understand that this is testing code that > normally aren't executed and thus for interoperability the current > proposed text is much safer. It could allow MTU discovery to work also > for IPv4 paths with MTU lower than 1280. In my mind, the MTU is a number configured on an interface; if the =20 interface is configured to not accept 100 byte packets we should =20 respond ICMP TOO BIG when we get a 100 byte packet. The question isn't =20= whether we generate the message in such a case, it's whether we allow =20= the network administrator to configure that small of a number. What would you like me to do with this comment? > 4. Section 3.1: TOS field > > When it comes to the parts that are the diffserv field, there is the > possibility that you like to remapp one set of code-points into =20 > another. > Should there be some text recommending that such function is =20 > supported, > or is it useless? As we discussed separately, the question is one of an administrative =20 boundary. At most, we should point to RFCs 2474 and 2475 and indicate =20= that in cases where the translator is implemented on a boundary where =20= DSCP translation is appropriate the implementor should enable that to =20= happen. > 5. Section 3.1, and also 2.1: > > Next header / Protocol field translation. There are a few that are =20 > IPv6 > specific shouldn't these be called out specific in this part? OK. Note that they weren't in the document that these sections are =20 inherited from and nobody has complained about that. Could you list =20 the ones you think are important to note? > Cheers > > Magnus Westerlund > (As individual contributor) > > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Mar 23 14:56: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 2C77B28C0F0 for ; Mon, 23 Mar 2009 14:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_SE=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 rq4lf8fJM9L4 for ; Mon, 23 Mar 2009 14:56:05 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1F6B83A6831 for ; Mon, 23 Mar 2009 14:56:05 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0293E21779; Mon, 23 Mar 2009 22:56:54 +0100 (CET) X-AuditID: c1b4fb3c-aef61bb000003f6e-7f-49c805a546d6 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B7C542095E; Mon, 23 Mar 2009 22:56:53 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 22:56:53 +0100 Received: from [153.88.45.200] ([153.88.45.200]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 22:56:51 +0100 Message-ID: <49C8059A.500@ericsson.com> Date: Mon, 23 Mar 2009 14:56:42 -0700 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fred Baker References: <49C4F74D.9010006@ericsson.com> <18F6D3DB-4436-4289-B245-3F174E0E675A@cisco.com> In-Reply-To: <18F6D3DB-4436-4289-B245-3F174E0E675A@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Mar 2009 21:56:52.0177 (UTC) FILETIME=[460A6C10:01C9AC02] X-Brightmail-Tracker: AAAAAA== Cc: xing@cernet.edu.cn, congxiao@cernet.edu.cn, Behave WG Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-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: Mon, 23 Mar 2009 21:56:07 -0000 Please see my comments inline. Fred Baker skrev: > > On Mar 21, 2009, at 7:18 AM, Magnus Westerlund wrote: > >> Hi, >> >> I have reviewed the draft and have some comments. >> >> 1. Section 2.2, first paragraph: >> >> When it comes to zero UDP checksums we do have a proposal to allow them >> also for IPv6/UDP packets draft-eubanks-chimento-6man-00. As this is for >> things like Automatic Multicast Tunneling, I guess that we will see >> these over a 64 translator. As this changes the assumption about that >> zero checksum isn't useful somewhat, do we need to care? > > I see that as a question for 6man. In a translator, either we require a > checksum in UDP, or we don't, in my view. Please don't ask me to try to > determine whether the UDP message is using some specific protocol. At > least one viewpoint would suggest that RFC 2460's insistence on the > checksum was an unauthorized change to a protocol not under discussion. > > Question for you, here. Are you asking us to flag the fact that a UDP > datagram transiting from an IPv4 network to an IPv6 network may require > a checksum calculation if it is zeroed? Personally, I would prefer to > see that done on the host or not at all. Think in the context of gigabit > links. I would rather give the translator the option of discarding the > datagram and telling the administrator to reconfigure his hosts. > This was primarily an observation about that the assumptions that this spec uses to motivate to drop fragments with zero checksum. Forcing reassembly in the translator do seems to be way to heavy a solution. So no change in my mind. >> 2. Section 2.3: >> >> Should we include required support for the ICMP extension header (RFC >> 4884) in the document? > > Tell me: is there anything that makes a strong statement about the > implementation of RFC 4884 in other systems? It seems like the level of > requirement here would be the same as the level of requirement in other > systems. The following documents seems to have references to RFC 4884: draft-atlas-icmp-unnumbered-06 rfc4950 (ICMP Extensions for Multiprotocol Label Switching) draft-shen-udp-traceroute-ext-01 draft-ietf-behave-nat-icmp-12 draft-ietf-shim6-proto-12 draft-wing-behave-nat-control-stun-usage-05 draft-wood-dna-link-properties-advertisement-01 draft-frejborg-hipv4-01 My understanding is that extensions are optional to use, and volunteer for end-systems to support them. > > I might be willing to see it as a "SHOULD". From my perspective (being > one of the editors who worked with normative language prior to Scott's > RFC defining the terms), I use "MUST" when the failure to do something > breaks something, and I try to say what broke. I use SHOULD when it is > something I would like to require but don't think failure to implement > actually breaks anything. I use MAY when there are those who care but > I'm not one of them. > > If I say that the implementer MUST implement 4884, then I think I am > duty bound to detail a section telling him how, and I think I am also > bound to tell him what will break if he doesn't - and I think that is > "RFC 4884 functionality". So in my mind, "MUST" doesn't fit. If there is > no statement to the effect that folks SHOULD implement RFC 4884 in other > places this one is an odd first choice in upping the ante. I could > imagine simply pointing to the document and making no requirement > statement at all. I think you are rushing to level of support before discussing what it actually means to handle ICMP extensions. > > Give me something solid to work from here? A translator can support header extensions by correctly fill in the length field modification it applies when translating the addresses. The translation should not go beyond the length field for the original datagram field to avoid changing the extension itself. If the ICMP extension isn't translated I think two cases exist: 1. That the translated packet is created from scratch and the length field never is filled in. Then an ICMP extension will result in that it will be treated as part of the original datagram field. 2. If the IP payload is copied and then modified then the length field will be unmodified while the original datagram field will become longer by the address translation from v4->v6. Thus cutting off the end of the original datagram field for ICMP extension aware receivers. What I haven't grasped is if anything in the extension part actually needs translation. Hopefully not. I think supporting the length field modifications are straight forward and avoids breaking things. Thus I would argue for MUST. > >> 3. Section 3, Path MTU Discovery: >> >> I think Dave Thaler talked about the possibility for actually >> originating ICMP too big messages that indicate packet sizes that are >> less than 1280 bytes. I can understand that this is testing code that >> normally aren't executed and thus for interoperability the current >> proposed text is much safer. It could allow MTU discovery to work also >> for IPv4 paths with MTU lower than 1280. > > In my mind, the MTU is a number configured on an interface; if the > interface is configured to not accept 100 byte packets we should respond > ICMP TOO BIG when we get a 100 byte packet. The question isn't whether > we generate the message in such a case, it's whether we allow the > network administrator to configure that small of a number. > > What would you like me to do with this comment? > I think we have different views on what MTU is, I probably should add Path before MTU to be clear. But that varies with the peer IP address in my mind, yes it can't go above the interface MTU, but it definitely can be smaller based on tunnels, etc, on the path. The question I do like to get community feedback that I don't haven't bee answered is: Is sending IPv6 packet to big messages with a value lower than 1280 bytes a possibility as better working alternative to do IPv4 fragmentation by sending packets with DF=0? >> 4. Section 3.1: TOS field >> >> When it comes to the parts that are the diffserv field, there is the >> possibility that you like to remapp one set of code-points into another. >> Should there be some text recommending that such function is supported, >> or is it useless? > > As we discussed separately, the question is one of an administrative > boundary. At most, we should point to RFCs 2474 and 2475 and indicate > that in cases where the translator is implemented on a boundary where > DSCP translation is appropriate the implementor should enable that to > happen. Agreed > >> 5. Section 3.1, and also 2.1: >> >> Next header / Protocol field translation. There are a few that are IPv6 >> specific shouldn't these be called out specific in this part? > > OK. Note that they weren't in the document that these sections are > inherited from and nobody has complained about that. Could you list the > ones you think are important to note? > The below ones are noted in the IPv6 parameters registry: http://www.iana.org/assignments/ipv6-parameters 5.a. Header types 00 = Hop-by-Hop Options 41 = ipv6 43 = Routing 44 = Fragment 51 = Authentication 60 = Destination Options 50 = Encapsulating Security Payload xx = Upper Layer Header 58 = Internet Control Message Protocol (ICMP) 59 - no next header For the "xx" values see the list of protocol numbers for the values to use for the upper layer ' For the protocol registry http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml The document accounts for Hop-by-hop, Routing, destination options are already accounted for by saying that they are not handled. IPv6 and ESP are simply payloads for the transport and shouldn't have any issues. AH (Authentication) will be broken by the translator. That might even be worth saying that it shall be dropped to not waste resources? Or is it better to deliver them to the end host and have the AH drop them? No Next header could potentially be an issue. The question from my part is if anyone knows what happens if a IPv4 packet contains value 59 in its Protocol field? Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dthaler@windows.microsoft.com Mon Mar 23 15: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 0861228C1C7 for ; Mon, 23 Mar 2009 15:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC00MIs135dT for ; Mon, 23 Mar 2009 15:44:36 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 441F128C1DA for ; Mon, 23 Mar 2009 15:44:36 -0700 (PDT) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 23 Mar 2009 15:45:26 -0700 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.2.99.4; Mon, 23 Mar 2009 15:45:25 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Mon, 23 Mar 2009 15:45:25 -0700 From: Dave Thaler To: "behave@ietf.org" Date: Mon, 23 Mar 2009 15:45:25 -0700 Thread-Topic: Volunteers for minutes and jabbering? Thread-Index: AcmsCQ56bUkReyNJQBiYePFwbGTmVw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E9CACA3D8417CE409FE3669AAE1E5A4F11DF0B42F2NAEXMSGW601wi_" MIME-Version: 1.0 Subject: [BEHAVE] Volunteers for minutes and jabbering? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 22:44:37 -0000 --_000_E9CACA3D8417CE409FE3669AAE1E5A4F11DF0B42F2NAEXMSGW601wi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are in need of volunteers for taking minutes and jabber scribing for the Behave WG meetings. Having at least 2 minute takers, plus a jabber scribe would be preferable. Please consider volunteering. Thanks, -Dave --_000_E9CACA3D8417CE409FE3669AAE1E5A4F11DF0B42F2NAEXMSGW601wi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are in need of volunteers for taking minutes and ja= bber scribing for the

Behave WG meetings.  Having at least 2 minute tak= ers, plus a jabber scribe

would be preferable.

 

Please consider volunteering.

 

Thanks,

-Dave

--_000_E9CACA3D8417CE409FE3669AAE1E5A4F11DF0B42F2NAEXMSGW601wi_-- From magnus.westerlund@ericsson.com Mon Mar 23 16:23: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 11FC43A696B for ; Mon, 23 Mar 2009 16:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_SE=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 KOz0qpZlRH-0 for ; Mon, 23 Mar 2009 16:23:17 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 42A743A6990 for ; Mon, 23 Mar 2009 16:22:59 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8BEA9207BB for ; Tue, 24 Mar 2009 00:23:48 +0100 (CET) X-AuditID: c1b4fb3e-aa7b2bb000006d6d-c6-49c81a0474f8 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6FEDB20103 for ; Tue, 24 Mar 2009 00:23:48 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 00:23:47 +0100 Received: from [153.88.45.200] ([153.88.45.200]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 00:23:47 +0100 Message-ID: <49C81A02.6090407@ericsson.com> Date: Mon, 23 Mar 2009 16:23:46 -0700 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Behave WG X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Mar 2009 23:23:47.0762 (UTC) FILETIME=[6AC58920:01C9AC0E] X-Brightmail-Tracker: AAAAAA== Subject: [BEHAVE] Comment on draft-bagnulo-behave-nat64-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: Mon, 23 Mar 2009 23:23:18 -0000 Hi, A general comment on the document is that in most cases where the solution isn't protocol specific the specification should be generic and simply say transport protocol, instead of TCP or UDP. The transport protocol specific parts already has its own section. The reason is that is should be clear what is protocol specific and what is general procedures. Currently the document specifies TCP and UDP but we have discussed extensions for DCCP and SCTP. To enable them to happen the document needs this generality. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dwing@cisco.com Mon Mar 23 18:19: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 C69EE3A6C26 for ; Mon, 23 Mar 2009 18:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 7YoMS0fwMdFE for ; Mon, 23 Mar 2009 18:19:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C620D3A6C65 for ; Mon, 23 Mar 2009 18:19:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,410,1233532800"; d="scan'208";a="145582831" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 24 Mar 2009 01:19:58 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2O1Jw1n012801; Mon, 23 Mar 2009 18:19:58 -0700 Received: from dwingwxp01 (sjc-vpn5-403.cisco.com [10.21.89.147]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2O1JvFe003689; Tue, 24 Mar 2009 01:19:58 GMT From: "Dan Wing" To: "'Magnus Westerlund'" , "'Fred Baker'" References: <49C4F74D.9010006@ericsson.com><18F6D3DB-4436-4289-B245-3F174E0E675A@cisco.com> <49C8059A.500@ericsson.com> Date: Mon, 23 Mar 2009 18:19:58 -0700 Message-ID: <04db01c9ac1e$a59bb050$7144150a@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: AcmsAkvlgBelhmKxQG+ROaxS8FBdwwAGwFyA In-Reply-To: <49C8059A.500@ericsson.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1020; t=1237857598; x=1238721598; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Comments=20on=20draft-baker- behave-v4v6-translation-02 |Sender:=20; bh=GPAPAJHElPqJn/XXC5LVMwJmIwTdxvchdRhUiKrp2TY=; b=DiUYdeUr4ptKZ8VucRBjc5y9VhEf9W/BstMYH/n2/IlfeeFMZ1XkV0ksCD M8Y59gVSXxlw6knJ6vRd/Bnc0X2iucIejqFPcbC3vTsXJQ7J1bEMP404y4SF qqgewnpgnq; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Behave WG' , congxiao@cernet.edu.cn, xing@cernet.edu.cn Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-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, 24 Mar 2009 01:19:08 -0000 ... > 2. If the IP payload is copied and then modified then the length field > will be unmodified while the original datagram field will > become longer > by the address translation from v4->v6. Thus cutting off the > end of the > original datagram field for ICMP extension aware receivers. > > What I haven't grasped is if anything in the extension part actually > needs translation. Hopefully not. At this time, none have been defined that need translation. We skirted around this in draft-ietf-behave-nat-icmp with ICMP Error payload may contain ICMP extension objects ([ICMP-EXT]). NATs are encouraged to support ICMP extension objects. At the time of this writing, the authors are not aware of any standard ICMP extension objects containing realm specific information. unfortunately if, in the future, someone puts 'realm specific' information into an extension, we have no way to identify it and know it needs to be NATted. I don't see a solution to that, though. -d From derek.macdonald@gmail.com Tue Mar 24 09:23: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 C4F833A69A6 for ; Tue, 24 Mar 2009 09:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 p2L6xK8mZAnb for ; Tue, 24 Mar 2009 09:23:49 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 24A363A6901 for ; Tue, 24 Mar 2009 09:23:49 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so2295051rvb.49 for ; Tue, 24 Mar 2009 09:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=NKRepJXrb/9EgG31MjOHZd/mbYblxww+PaWFlRzOs1s=; b=voJsFKcfARtv7CvF2ZH9GmM8IwOp0Rk/+eMTK+37A3KkSj16J2vXATTjMryWKMjvjL lY9PFAmo5ZPXznJKtMXI9FKLkGN190foReBb/yQ7KJD4bBfd+ERiAPKEhEA1Z3QaBOPJ ip+n8vMJ02FcsD09zYYPqMP2HIqaovw6Gm4U8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=h3J1nbs6qul6sPrPOPR+1t7Gz5sBDjLwSMKHLn3h4vXtsqE3jPMd6I+WmwhdUU+amm S3tyOul2/qTWc7qQFGasqIjVL4O/0/y05kJvXj2dRtN3RonHqmy+YxSs+FR6GnU2CLyW D5Q1RrNy4gR+JICJZJiInd1XXUULr31/KEQvc= MIME-Version: 1.0 Sender: derek.macdonald@gmail.com Received: by 10.114.200.2 with SMTP id x2mr5726683waf.83.1237911880272; Tue, 24 Mar 2009 09:24:40 -0700 (PDT) Date: Tue, 24 Mar 2009 09:24:40 -0700 X-Google-Sender-Auth: 0ce707262b3dbd3f Message-ID: From: Derek MacDonald To: Behave WG Content-Type: multipart/alternative; boundary=001636458000e30bb70465dfd109 Subject: [BEHAVE] Comment on turn-tcp Section 4.3 and 4.4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 24 Mar 2009 17:00:43 -0000 --001636458000e30bb70465dfd109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In section 4.3 and 4.4 of draft-ietf-behave-turn-tcp-02.txt there is a repeated sentence: This connection MUST be made using a different local IP address and port. Should this read: This connection MUST be made using a different local IP address or port. Probably a typo, but a mildly alarming one:) -Derek --001636458000e30bb70465dfd109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In section 4.3 and 4.4 of=A0 draft-ietf-behave-turn-tcp-02.
txt there is a repeated sentence:

This connection M= UST be made using a different local IP address and port.

Should this= read:

This connection MUST be made using a different local IP address or port= .

Probably a typo, but a mildly alarming one:)

-Derek
--001636458000e30bb70465dfd109-- From brian.e.carpenter@gmail.com Tue Mar 24 10:49: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 9019E28C0DC for ; Tue, 24 Mar 2009 10:49:35 -0700 (PDT) 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 62W7Gki-FE4O for ; Tue, 24 Mar 2009 10:49:34 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 8DF653A6928 for ; Tue, 24 Mar 2009 10:49:33 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3440290wfg.31 for ; Tue, 24 Mar 2009 10:50:24 -0700 (PDT) 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=laWC04RbaWzvuz2Tz87pV+QATVE310N+IumG+ucTIuw=; b=cgt3cBiAwgnp9QxQOS1DPsWd5MiKWbPnV6MsT2dddtfMyGlb+5pMYA5MD+51VgSdHC Z0cMHyl64YlSzZbb+XyCG3OKW9caUprNFwKDgTgpwAKqB5GBu0uuMaRXHsiAHuIeNYvx Ax2Y07sDLJHLjwhWURQU7G4f1aJwmSaj6ftmw= 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=R2HWchHvD4p+u9U1TAOViSHiHLukloO/naeGrYRpNPl+4tkZkFHTfGX2j3b+jUyMBo y+lRsuvf6uSbZe7rbg+a4EqzhZTb+fz1Hq63P96BZP7Hm9W1WwEUxJfp8qEJ8MPG/rE0 NoRUcr7+mq/4pnlMAyVYR4qihrTkz8FZ5JUms= Received: by 10.142.177.5 with SMTP id z5mr1209972wfe.346.1237917024944; Tue, 24 Mar 2009 10:50:24 -0700 (PDT) Received: from ?130.129.18.229? (dhcp-12e5.meeting.ietf.org [130.129.18.229]) by mx.google.com with ESMTPS id 31sm13942373wff.56.2009.03.24.10.50.22 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Mar 2009 10:50:24 -0700 (PDT) Message-ID: <49C91D40.5070508@gmail.com> Date: Wed, 25 Mar 2009 06:49:52 +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: <20080610150002.0D87F3A6913@core3.amsl.com><4855918D.7060600@gma il.com> <48563F0F.7060203@it.uc3m.es> <4856E9EA.9070102@gmail.com> <48576D5B.6000803@it.uc3m.es> <48583496.9080605@gmail.com> <485A4B71.1060308@it.uc3m.es> <49333BF2.20206@gmail.com> <493399F1.9050002@it.uc3m.es> In-Reply-To: <493399F1.9050002@it.uc3m.es> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: [BEHAVE] Handling error reponses in draft-bagnulo-behave-dns64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 24 Mar 2009 17:49:35 -0000 Repeating the old question I raised at the microphone. The draft says that if there is no A record, DNS64 will return the error response to the stub resolver. If I understand things correctly, DNS responses include the original query. If DNS64 does literally what the draft says, it will return a response to the stub resolver containing its own A query and not the stub's AAAA query. That seems wrong in principle, and it isn't obvious to me that a legacy resolver would process the response correctly. Brian On 2008-12-01 21:01, marcelo bagnulo braun wrote: > Brian E Carpenter escribi=C3=B3: >> This is still open from the old draft. It's section 3.1 >> in the new draft: >> >> On 2008-06-20 00:05, marcelo bagnulo braun wrote: >> >> =20 >>>>>>> If this query results in an empty result or in >>>>>>> an error, this result is returned to the client. =20 >>>>>>> =20 >>>>>> Even in this case, the result has to be synthetic I think >>>>>> (original AAAA query followed by empty answer or error). >>>>>> >>>>>> =20 >>>>> don't know >>>>> why do you think this is needed? >>>>> =20 >>>> I don't fully understand what DNS error replies look like, >>>> but I think they include the original query type. If so, the >>>> resolver code might get confused if the error reply to a AAAA >>>> query contained query type A. >>>> >>>> =20 >>> ok, let's get some dns experts to look at this >>> =20 >> >> And a similar point later in the new draft: >> >> =20 >>> 4.3.1. An-IPv6-network-to-IPv4-Internet >>> =20 >> ... >> =20 >>> 3. If the CD is set and DO is set, then it SHOULD NOT perform >>> validation, and it SHOULD NOT perform translation. It SHOULD >>> hand the data back to the query initiator, just like a regular= >>> recursing server, and depend on the client to do the validatio= n >>> and the translation itself. >>> =20 >> >> This is very odd - the stub resolver asks for a AAAA record >> and gets back an A record. I really don't know if that's going >> to work. >> =20 > Of course, this requires the stub resolver to be upgraded to understand= > this > We are working in an alternative behaviour, proposed by people in dnsop= s > presentation. >=20 > We hope to have a new version sometime soon. >=20 > Regards, marcelo >=20 >> Brian >> >> =20 >=20 >=20 From remi.despres@free.fr Tue Mar 24 14:46: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 5725328C1F2; Tue, 24 Mar 2009 14:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.87 X-Spam-Level: X-Spam-Status: No, score=0.87 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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 tBmNsTiY-si5; Tue, 24 Mar 2009 14:46:25 -0700 (PDT) Received: from smtp20.orange.fr (unknown [193.252.22.29]) by core3.amsl.com (Postfix) with ESMTP id 785E828C1EA; Tue, 24 Mar 2009 14:46:25 -0700 (PDT) Received: from dhcp-17b6.meeting.ietf.org (dhcp-17b6.meeting.ietf.org [130.129.23.182]) by mwinf2013.orange.fr (SMTP Server) with ESMTP id 1ED5720000A3; Tue, 24 Mar 2009 22:47:14 +0100 (CET) X-ME-UUID: 20090324214715126.1ED5720000A3@mwinf2013.orange.fr Message-ID: <49C95464.6080008@free.fr> Date: Tue, 24 Mar 2009 14:45:08 -0700 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Internet Area , Softwires WG , Behave WG , 6AI BOF , Shara BOF Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: [BEHAVE] draft-despres-sam-02 is now 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: Tue, 24 Mar 2009 21:46:26 -0000 FWI, draft-despres-sam-02  has just been posted.
Its URL is : www.ietf.org/internet-drafts/draft-despres-sam-02

As previously indicated:
- Sections 2, 3.5, 4.1 and 5 directly concern the debate about NAT66 (6IA BOF)
- Section 3.7 concerns directly Port Range extension of IPv4 addresses (Shara BOF)

It differs slightly from the version I sent by mail when the submission tool was closed:
- a few typos and bugs in the examples are corrected.
- it refers to the e2e "model" rather than to the e2e "principle" (thanks to Margaret and Brian for noting the mistake).

Sorry I couldn't number it -03 due to the submission tool which requires consecutive numbers.

Questions and comments are most welcome.

Regards,

RD
From dthaler@windows.microsoft.com Tue Mar 24 15:59: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 DE81E3A6C50 for ; Tue, 24 Mar 2009 15:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.493 X-Spam-Level: X-Spam-Status: No, score=-110.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orKUMmBOHXQu for ; Tue, 24 Mar 2009 15:59:16 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 129103A67F5 for ; Tue, 24 Mar 2009 15:59:16 -0700 (PDT) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 24 Mar 2009 16:00:07 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.2.99.4; Tue, 24 Mar 2009 15:40:53 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Tue, 24 Mar 2009 15:40:53 -0700 From: Dave Thaler To: Magnus Westerlund , Fred Baker Date: Tue, 24 Mar 2009 15:40:50 -0700 Thread-Topic: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-02 Thread-Index: AcmsAr4SK3sUM/HuSMSGz1x5iJDoIAAzidLQ Message-ID: References: <49C4F74D.9010006@ericsson.com> <18F6D3DB-4436-4289-B245-3F174E0E675A@cisco.com> <49C8059A.500@ericsson.com> In-Reply-To: <49C8059A.500@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Behave WG Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-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, 24 Mar 2009 22:59:17 -0000 Magnus wrote: [...] > >> 3. Section 3, Path MTU Discovery: > >> > >> I think Dave Thaler talked about the possibility for actually > >> originating ICMP too big messages that indicate packet sizes that > are > >> less than 1280 bytes. I can understand that this is testing code > that > >> normally aren't executed and thus for interoperability the current > >> proposed text is much safer. It could allow MTU discovery to work > also > >> for IPv4 paths with MTU lower than 1280. [...] Magnus, The text I referred to is from RFC 2460 section 5, which states: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. draft-baker-behave-v4v6-translation-02 section 3 already refers to this: An IPv6 link has to have an MTU of 1280 bytes or greater. The corresponding limit for IPv4 is 68 bytes. Thus, unless there were special measures, it would not be possible to do end-to-end path MTU discovery when the path includes an translator since the IPv6 node might receive ICMP "packet too big" messages originated by an IPv4 router that report an MTU less than 1280. However, [RFC2460] requires that IPv6 nodes handle such an ICMP "packet too big" message by reducing the path MTU to 1280 and including an IPv6 fragment header with each packet. This allows end-to-end path MTU discovery across the translator as long as the path MTU is 1280 bytes or greater. When the path MTU drops below the 1280 limit the IPv6 sender will originate 1280 byte packets that will be fragmented by IPv4 routers along the path after being translated to IPv4. I would only suggest a trivial change here to help the reader, namely change "[RFC2460]" to "[RFC2460] section 5". -Dave From magnus.westerlund@ericsson.com Tue Mar 24 16:16: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 00CF73A6821 for ; Tue, 24 Mar 2009 16:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_SE=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 YiAQDxL9kEWY for ; Tue, 24 Mar 2009 16:16:25 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B95A53A681D for ; Tue, 24 Mar 2009 16:16:24 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7133920007; Wed, 25 Mar 2009 00:16:09 +0100 (CET) X-AuditID: c1b4fb3c-ae760bb000003f6e-ce-49c969b991fb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 40DD6214BC; Wed, 25 Mar 2009 00:16:09 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 00:16:08 +0100 Received: from [153.88.48.25] ([153.88.48.25]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 00:16:07 +0100 Message-ID: <49C969B6.7080601@ericsson.com> Date: Tue, 24 Mar 2009 16:16:06 -0700 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dave Thaler References: <49C4F74D.9010006@ericsson.com> <18F6D3DB-4436-4289-B245-3F174E0E675A@cisco.com> <49C8059A.500@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 24 Mar 2009 23:16:08.0159 (UTC) FILETIME=[833D6EF0:01C9ACD6] X-Brightmail-Tracker: AAAAAA== Cc: Behave WG , Fred Baker Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-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, 24 Mar 2009 23:16:26 -0000 Thanks Dave, I apparently misinterpreted the text that you quote. It might be the paragraph that follows that through me off: The only drawback with this scheme is that it is not possible to use PMTU to do optimal UDP fragmentation (as opposed to completely avoiding fragmentation) at sender since the presence of an IPv6 Fragment header is interpreted that is it OK to fragment the packet on the IPv4 side. Thus if a UDP application wants to send large packets independent of the PMTU, the sender will only be able to determine the path MTU on the IPv6 side of the translator. If the path MTU on the IPv4 side of the translator is smaller then the IPv6 sender will not receive any ICMP "too big" errors and can not adjust the size fragments it is sending. By having this discussion it is implied that we should at least discuss changing the IPv6 spec. I think that is unnecessary. We have to live with this. Magnus Dave Thaler skrev: > Magnus wrote: > [...] >>>> 3. Section 3, Path MTU Discovery: >>>> >>>> I think Dave Thaler talked about the possibility for actually >>>> originating ICMP too big messages that indicate packet sizes that >> are >>>> less than 1280 bytes. I can understand that this is testing code >> that >>>> normally aren't executed and thus for interoperability the current >>>> proposed text is much safer. It could allow MTU discovery to work >> also >>>> for IPv4 paths with MTU lower than 1280. > [...] > > Magnus, > > The text I referred to is from RFC 2460 section 5, which states: > > In response to an IPv6 packet that is sent to an IPv4 destination > (i.e., a packet that undergoes translation from IPv6 to IPv4), the > originating IPv6 node may receive an ICMP Packet Too Big message > reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node > is not required to reduce the size of subsequent packets to less than > 1280, but must include a Fragment header in those packets so that the > IPv6-to-IPv4 translating router can obtain a suitable Identification > value to use in resulting IPv4 fragments. Note that this means the > payload may have to be reduced to 1232 octets (1280 minus 40 for the > IPv6 header and 8 for the Fragment header), and smaller still if > additional extension headers are used. > > draft-baker-behave-v4v6-translation-02 section 3 already refers to this: > > An IPv6 link has to have an MTU of 1280 bytes or greater. The > corresponding limit for IPv4 is 68 bytes. Thus, unless there were > special measures, it would not be possible to do end-to-end path MTU > discovery when the path includes an translator since the IPv6 node > might receive ICMP "packet too big" messages originated by an IPv4 > router that report an MTU less than 1280. However, [RFC2460] > requires that IPv6 nodes handle such an ICMP "packet too big" message > by reducing the path MTU to 1280 and including an IPv6 fragment > header with each packet. This allows end-to-end path MTU discovery > across the translator as long as the path MTU is 1280 bytes or > greater. When the path MTU drops below the 1280 limit the IPv6 > sender will originate 1280 byte packets that will be fragmented by > IPv4 routers along the path after being translated to IPv4. > > I would only suggest a trivial change here to help the reader, namely > change "[RFC2460]" to "[RFC2460] section 5". > > -Dave > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From wangxuewei@huawei.com Tue Mar 24 19:13: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 8582E3A6B0A for ; Tue, 24 Mar 2009 19:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-1.494, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, 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 LJUnOVq1gaU0 for ; Tue, 24 Mar 2009 19:13:11 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A0BFD3A68B6 for ; Tue, 24 Mar 2009 19:12:41 -0700 (PDT) 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 <0KH100H7EHPCFO@szxga04-in.huawei.com> for behave@ietf.org; Wed, 25 Mar 2009 10:03:12 +0800 (CST) Received: from w00104636 ([10.111.12.168]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KH100E47HPB1Y@szxga04-in.huawei.com> for behave@ietf.org; Wed, 25 Mar 2009 10:03:11 +0800 (CST) Date: Wed, 25 Mar 2009 10:03:08 +0800 From: wangxuewei To: Dan Wing Message-id: <006001c9aced$d8115150$a80c6f0a@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.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_aRkNQN7KIP3/GFhGWvcPCQ)" X-Priority: 3 X-MSMail-priority: Normal References: <017601c9a719$377b7ab0$c2f0200a@cisco.com> <015801c9a871$8e723530$a80c6f0a@china.huawei.com> <015701c9aa77$728a5bb0$c2f0200a@cisco.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] Learning the IPv6 Prefix of a NAT64(draft-wing-behave-learn-prefix-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: Wed, 25 Mar 2009 02:13:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_aRkNQN7KIP3/GFhGWvcPCQ) Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7BIT Perhaps you misunderstand my meanings. AFT serving as router uses dynamic routing protocol to pass the prefix and length to edge routers, and edge routers use RA message to pass the prefix and length to subscribes. The purpose of this process is to make IPv6 hosts learn the prefix and length, not learn the route from host to AFT. As for the route,subscribers can use default routes as with today's IPv4 to edge routers. Xuewei Wang ----- Original Message ----- From: Dan Wing To: 'wangxuewei' ; behave@ietf.org Sent: Sunday, March 22, 2009 6:50 AM Subject: RE: [BEHAVE] Learning the IPv6 Prefix of a NAT64(draft-wing-behave-learn-prefix-01) > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of wangxuewei > Sent: Thursday, March 19, 2009 2:03 AM > To: Dan Wing; behave@ietf.org > Subject: Re: [BEHAVE] Learning the IPv6 Prefix of a > NAT64(draft-wing-behave-learn-prefix-01) > > hi, > > read through your draft draft-wing-behave-learn-prefix-01 > ,the IPv6 prefix and the prefix length can be learned using > DNS or DHCP. > > what i think is there exists another method of learning the > prefix and length by Router Advertisement (RA) message, for > the IPv6 host attaches to the same multicast link as AFT, AFT > can directly periodically advertise(or in response to valid > Router Solicitations) RA messages containing the /96 prefix > and length to the IPv6 host. That seems reasonable. > For the IPv6 host attaches to the different multicast link > with AFT, we can make AFT use dynamic routing protocol > (OSPF$B!"(BISIS etc) to announce the /96 prefix and length to edge > routers in the IPv6 domain, thus edge routers in the IPv6 > domain obtain the /96 prefix and length, they can > periodically advertise(or in response to valid Router > Solicitations) RA messages containing the /96 prefix and length. Today, at least, dynamic routing protocols aren't propagated to subscribers. Is that expected to change with IPv6, or would most subscribers use default routes as with today's IPv4? > how do you think this method ? -d > thanks > > > Xuewei Wang > > ----- Original Message ----- > From: Dan Wing > To: behave@ietf.org > Sent: Tuesday, March 17, 2009 11:58 PM > Subject: [BEHAVE] Learning the IPv6 Prefix of a > NAT64(draft-wing-behave-learn-prefix-01) > > Last week I submitted a new version of "Learning the > IPv6 Prefix of a NAT64", > > http://tools.ietf.org/html/draft-wing-behave-learn-prefix-01. > It describes > how an application can learn the prefix of its NAT64 > via DNS or via DHCP. The > DNS query would be sent to its DNS server, which is its > DNS64 if the service > provider is running a DNS64+NAT64. DHCP is > per-interface. Both the DNS and > DHCP methods allow the host to choose different NAT64s > for different purposes > (cost, performance, type of link). > > The significant change in this version is that a DNS > NAPTR query is sent, > rather than querying for a TXT record. > > I do not intend to present this document in San > Francisco. Rather, this > document exists to show it is possible for applications > to learn the NAT64 > prefix if they need to construct synthetic IPv6 > addresses themselves. So far, > only three applications have been identified which > might benefit from this > functionality: DNSSEC, BitTorrent, and SIP. > > Comments welcome. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > --Boundary_(ID_aRkNQN7KIP3/GFhGWvcPCQ) Content-type: text/html; charset=iso-2022-jp Content-transfer-encoding: 7BIT
Perhaps you misunderstand my meanings.
 
AFT serving as router uses dynamic routing protocol to pass the prefix and length to edge routers, 
and edge routers use RA message to pass the prefix and length to subscribes.
The purpose of this process is to make IPv6 hosts learn the prefix and length, not learn the route from host to AFT.
 
As for the route,subscribers can use default routes as with today's IPv4 to edge routers.
 
 
 
Xuewei Wang
----- Original Message -----
From: Dan Wing
Sent: Sunday, March 22, 2009 6:50 AM
Subject: RE: [BEHAVE] Learning the IPv6 Prefix of a NAT64(draft-wing-behave-learn-prefix-01)



> -----Original Message-----
> From: behave-bounces@ietf.org
> [mailto:behave-bounces@ietf.org] On Behalf Of wangxuewei
> Sent: Thursday, March 19, 2009 2:03 AM
> To: Dan Wing; behave@ietf.org
> Subject: Re: [BEHAVE] Learning the IPv6 Prefix of a
> NAT64(draft-wing-behave-learn-prefix-01)
>
> hi,
>
> read through your draft draft-wing-behave-learn-prefix-01
> ,the IPv6 prefix and the prefix length can be learned using
> DNS or DHCP.
> 
> what i think is there exists another method of learning the
> prefix and length by Router Advertisement (RA) message, for
> the IPv6 host attaches to the same multicast link as AFT, AFT
> can directly periodically advertise(or in response to valid
> Router Solicitations) RA messages containing the /96 prefix
> and length to the IPv6 host.

That seems reasonable.

> For the IPv6 host attaches to the different multicast link
> with AFT, we can make AFT use dynamic routing protocol
> (OSPF$B!"(BISIS etc) to announce the /96 prefix and length to edge
> routers in the IPv6 domain, thus edge routers in the IPv6
> domain obtain the /96 prefix and length, they can
> periodically advertise(or in response to valid Router
> Solicitations) RA messages containing the /96 prefix and length.

Today, at least, dynamic routing protocols aren't propagated to subscribers.
Is that expected to change with IPv6, or would most subscribers use default
routes as with today's IPv4? 

> how do you think this method ?

-d


> thanks
> 
> 
> Xuewei Wang
>
> ----- Original Message -----
> From: Dan Wing <mailto:dwing@cisco.com> 
> To: behave@ietf.org
> Sent: Tuesday, March 17, 2009 11:58 PM
> Subject: [BEHAVE] Learning the IPv6 Prefix of a
> NAT64(draft-wing-behave-learn-prefix-01)
>
> Last week I submitted a new version of "Learning the
> IPv6 Prefix of a NAT64",
>
> http://tools.ietf.org/html/draft-wing-behave-learn-prefix-01.
>  It describes
> how an application can learn the prefix of its NAT64
> via DNS or via DHCP.  The
> DNS query would be sent to its DNS server, which is its
> DNS64 if the service
> provider is running a DNS64+NAT64.  DHCP is
> per-interface.  Both the DNS and
> DHCP methods allow the host to choose different NAT64s
> for different purposes
> (cost, performance, type of link).
>
> The significant change in this version is that a DNS
> NAPTR query is sent,
> rather than querying for a TXT record.
>
> I do not intend to present this document in San
> Francisco.  Rather, this
> document exists to show it is possible for applications
> to learn the NAT64
> prefix if they need to construct synthetic IPv6
> addresses themselves.  So far,
> only three applications have been identified which
> might benefit from this
> functionality:  DNSSEC, BitTorrent, and SIP.
>
> Comments welcome.
>
> -d
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>
>
--Boundary_(ID_aRkNQN7KIP3/GFhGWvcPCQ)-- From jhw@apple.com Wed Mar 25 09:56: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 6BD593A67FD for ; Wed, 25 Mar 2009 09:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.019 X-Spam-Level: X-Spam-Status: No, score=-106.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id at5TAypC2ih6 for ; Wed, 25 Mar 2009 09:56:22 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id A64E93A6AE4 for ; Wed, 25 Mar 2009 09:56:22 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 44D485B769D2 for ; Wed, 25 Mar 2009 09:57:15 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Brightmail Gateway) with ESMTP id 2F39428080 for ; Wed, 25 Mar 2009 09:57:15 -0700 (PDT) X-AuditID: 11807130-a9893bb000000fcd-6a-49ca626bc33c Received: from [17.151.121.35] (unknown [17.151.121.35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id 12ACD2807F for ; Wed, 25 Mar 2009 09:57:15 -0700 (PDT) Message-Id: <22B4ECC9-8466-4866-B9DF-1A2866830BCC@apple.com> From: james woodyatt To: "behave@ietf.org WG" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 09:57:14 -0700 X-Mailer: Apple Mail (2.930.3) X-Brightmail-Tracker: AAAAAA== Subject: [BEHAVE] comment draft-nishitani-cgn X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 16:56:23 -0000 everyone-- I don't see any requirement for dynamic port forwarding. There should be such a requirement. -- james woodyatt member of technical staff, communications engineering From miyakawa@nttv6.jp Wed Mar 25 10:11: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 1437928C147 for ; Wed, 25 Mar 2009 10:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 L0NZJcP5gXVM for ; Wed, 25 Mar 2009 10:11:41 -0700 (PDT) Received: from gura.nttv6.jp (gura.nttv6.jp [IPv6:2001:218:1f01:2::2]) by core3.amsl.com (Postfix) with ESMTP id C808228C141 for ; Wed, 25 Mar 2009 10:11:40 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 54C4CBDC08; Thu, 26 Mar 2009 02:12:32 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 2CFD96FD83; Thu, 26 Mar 2009 02:12:32 +0900 (JST) Date: Thu, 26 Mar 2009 02:12:32 +0900 (JST) Message-Id: <20090326.021232.104121077.miyakawa@nttv6.jp> To: jhw@apple.com From: Shin Miyakawa In-Reply-To: <22B4ECC9-8466-4866-B9DF-1A2866830BCC@apple.com> References: <22B4ECC9-8466-4866-B9DF-1A2866830BCC@apple.com> Organizaton: NTT Communications X-Mailer: Mew version 6.1 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: miyakawa@nttv6.jp, behave@ietf.org Subject: Re: [BEHAVE] comment draft-nishitani-cgn X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 17:11:42 -0000 James, > I don't see any requirement for dynamic port forwarding. There should be such a requirement. OK. Let us think about this too. (and please give us a text you like or join as a author) As I said at the mic, this draft is not matured yet and compiled by non-native English speakers, so please help us to complete. Shin Miyakawa, Ph.D Director, Core Network Technology Team, Network Systems and Technologies, Innovative IP Architecture Center / Corporate Planning Department (concurrent position) NTT Communications Corporation Gran Park Tower 17F 3-4-1 Shibaura, Minato-ku, Tokyo 108-8118 Japan E-mail:miyakawa@nttv6.jp / shin.miyakawa@ntt.com / miyakawa@wide.ad.jp TEL: +81-50-3812-4695, FAX: +81-3-5439-0490 Visiting Researcher, SFC Lab. KEIO University WIDE Project From remi.despres@free.fr Wed Mar 25 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 247733A6D3B; Wed, 25 Mar 2009 10:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.429 X-Spam-Level: X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, 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 q5saTFIcUcIB; Wed, 25 Mar 2009 10:32:40 -0700 (PDT) Received: from smtp20.orange.fr (unknown [80.12.242.27]) by core3.amsl.com (Postfix) with ESMTP id A81E33A68AB; Wed, 25 Mar 2009 10:32:39 -0700 (PDT) Received: from dhcp-17b6.meeting.ietf.org (dhcp-17b6.meeting.ietf.org [130.129.23.182]) by mwinf2009.orange.fr (SMTP Server) with ESMTP id E04311C000AB; Wed, 25 Mar 2009 18:33:29 +0100 (CET) X-ME-UUID: 20090325173329918.E04311C000AB@mwinf2009.orange.fr Message-ID: <49CA6A6A.2080502@free.fr> Date: Wed, 25 Mar 2009 10:31:22 -0700 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Margaret Wasserman References: <492C40D8.2040401@free.fr> <492D1937.2020001@free.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: Behave WG , Fred Baker , nat66@ietf.org Subject: Re: [BEHAVE] Non reversibility of address mappings in the "NAT66" 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, 25 Mar 2009 17:32:42 -0000 Margaret, Better late than never, comments below. Regards, RD Margaret Wasserman - le (m/j/a) 9/14/31 11:59 AM: > > Hi Remi, > > I ran some numbers this morning, and you are right. > > If the _original_ value of the 16-bit checksum correction field is > 0x0000, it will be restored to 0xFFFF, which is wrong. The checksum > correction works fine (as Fred's tests have proven), but the > restoration of the value doesn't work properly. It can be made to > work properly for either 0x0000 or 0xFFFF, but I haven' t figured out > a way to make it work right for both values as the information to > distinguish between them is lost. > > There are three approaches we can take to fix this > > 1) As you have proposed, we could changing NAT66 so that it modifies > the transport header checksum. > This would involve every NAT66 box knowing how to traverse the IPv6 > extension header chain, Yes, but IMHO this is not very complex, even in limit cases, and very fast in typical cases. > and might effectively limit IPv6 NAT to transporting ICMPv6, TCP and > UDP-based protocols, because we wouldn't know how to correct the > checksum in other protocols. Could you explain? I don't see this limit: - If there is no transport, then no checksum adjustment is not needed. - For other transport protocols than TCP and UDP, the problem seems to be the same with your proposal (it assumes one's complement checksum in the transport protocol.) > > 2) The NAT66 device can store one-bit-per-host of state for any host > that has 0xFFFF or 0x0000 in the field that is used for the checksum > correction. Finding the tra&nsport next header seems simpler, and in any case stateless, which is important for scalability. > Although we would be required to implement this, we could explain to > network administrators how to avoid it, at least in the case where the > bits used for checksum correction are the subnet bits. IMHO, a terrible perspective, to be avoided by all means. > I'm not sure if this would be better or worse than updating the > transport layer checksum, though, as it would result in inferior > service for a small set of hosts, but would provide better service to > most hosts. > > 2) We can do the checksum correction in a 16-bit field that we _know_ > will never contain one of the two one's complement 0 values (0x0000 or > 0xFFFF). There are two different cases here, but I think there are > choices for both that would work: I don't see this working. The problem seems more an intrinsic characteristic of One's complement, but looking at detailed cases could be necessary to reach a common understanding. > 2a) For the case of /48 or shorter prefixes, we could still do the > checksum correction in the lowest order 16 subnet bits and document > that subnet values containing 0xFFFF in their lowest order 16 bits > should not be used with NAT66. This has the advantage of retaining > the IID value unchanged, but might result in some misconfigurations > and support calls. Same concern. > > 2b) For longer prefixes, we could perform the checksum correction in > the highest order 16 bits of the IID. > I've looked into this in the IEEE specs, and we should never have an > IID with both the "g" bit and the "u" bit set. True for full 64 bit IIDs, but subnet prefixes longer than /64 are already considered for some cases. They should not be made impossible just because a one's complement problem has not been solved as it should, i.e. without interfering with IPv6 address formats. > The "g" (individual/group) bit should always be '0' in EUI 64s that > are assigned to specific interfaces (a "1" indicates that this is a > "group" address, similar to an Ethernet multicast address), and if a > host uses an IID that was generated some other way, it is expected to > clear the "u" bit to indicate that the value isn't a universally > scoped EUI-64. So, we should be able to safely assume that the first > 2 bits of an IID will never be "11". Therefore, the first 16 bits can > never contain 0xFFFF. The issues here is that we would end-up > generating IIDs that have the "universal" bit set that are not > universally scoped. I am not sure how big of an issue that is, as we > don't have any documents that use the fact that a universally scoped > IID contains an EUI-64, at least not to my knowledge. > > Thoughts? See above. > > > Margaret > > > > On Nov 26, 2008, at 4:39 AM, Rémi Després wrote: > >> Fred Baker (1-12/1-31/200x) 11/24/08 10:23 PM: >>> >>> Not sure I buy that. In UDP and TCP, the value stored in the header >>> is set of 0xFFFF if the sum adds to 0x0000, but I don't see any >>> reason that has to be the case in the modification of the IP address. >> No reason, you are right, but the point I was making is different. >> >> It concerns the 16 bits in which the prefix checksum difference is >> subtracted, in outgoing packets, when these 16 bits happen to be 0000 >> (i.e. +0 in one's complement). After the subtraction, which in >> general gives a non-zero result, it will no longer be possible to >> determine whether the original value was -0 or +0. >> >> If the checksum difference to be subtracted from 0000 is for example >> 0001, the result is FFFE (i.e. - 1). >> >> When trying to reverse the mapping, adding 0001 to FFFE gives FFFF >> (i.e. -0), while the original value in the outbound packet was 0000 >> (i.e. +0) :-(. >>> >>> I'll let you look at the code I put up to test this if you like. You >>> can tell me what I missed. >>> ftp://ftpeng.cisco.com/fred/gse/checksum.c >> What had been missed is not in the code, which seems perfectly fine, >> but in the specification. >> >> Regards, >> >> RD >>> On Nov 25, 2008, at 10:15 AM, Rémi Després wrote: >>> >>>> Margaret, Fred, >>>> >>>> In section 5.1 of your draft, you propose a technique for >>>> Checksum-Neutral Mapping. >>>> >>>> Due to the two ways to represent 0 in one's complement, it doesn't >>>> work in all cases: >>>> >>>> In 16 bits, +0 is 0x0000 and -0 is 0xFFFF. >>>> >>>> If the field which is modified contains -0 or +0, adding to it, or >>>> subtracting from it, any non zero value wipes out the difference >>>> between the two zeros. >>>> >>>> For example, in one's complement: >>>> . 0x0000 - 0x0001 = 0xFFFE >>>> . 0xFFFF - 0x0001 = 0xFFFE >>>> >>>> I therefore believe that it is unavoidable to modify the UDP or TCP >>>> checksum if we want a reversible mapping between a local and a >>>> global address (which I believe is a good approach to avoid >>>> classical NATs in IPv6). This modification can be done >>>> incrementally. Finding the UDP/TCP header may require in IPv6 to >>>> parse a few headers, but this seems quite acceptable. >>>> >>>> Regards, >>>> >>>> RD >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>> >> >> > > > From jhw@apple.com Wed Mar 25 11:26: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 525733A6D81 for ; Wed, 25 Mar 2009 11:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.004 X-Spam-Level: X-Spam-Status: No, score=-106.004 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kGlBhoQAnm8 for ; Wed, 25 Mar 2009 11:26:30 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 862183A6D70 for ; Wed, 25 Mar 2009 11:26:30 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 478D25B7C889 for ; Wed, 25 Mar 2009 11:27:23 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Brightmail Gateway) with ESMTP id 2C64C28088 for ; Wed, 25 Mar 2009 11:27:23 -0700 (PDT) X-AuditID: 1180711d-ab82bbb000000ff0-c7-49ca778a81ce Received: from [17.151.121.35] (unknown [17.151.121.35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay13.apple.com (Apple SCV relay) with ESMTP id C8FB02807D for ; Wed, 25 Mar 2009 11:27:22 -0700 (PDT) Message-Id: <57A37ACC-1E0A-42F1-A8B8-B06936F9F062@apple.com> From: james woodyatt To: "behave@ietf.org WG" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 11:27:21 -0700 X-Mailer: Apple Mail (2.930.3) X-Brightmail-Tracker: AAAAAA== Subject: [BEHAVE] comments draft-denis-behave-v4v6exthdr X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 18:26:31 -0000 everyone-- I had a brain-fade and didn't register with me that, yes, in fact, I had read the draft before the presentation. I have two comments: p1. As Dave Thaler argued, there may be multiple legacy NAT44s in the path from any particular IPv4 source to an IPv6 destination, and the utility of the information inserted by a NAT64 with this extension header for making address referrals to other IPv4-translated peers of an IPv6 node is therefore basically epsilon. p2. I think it may be premature to take up this work for another reason. Until the 6AI controversy is concluded, I think we cannot yet say with certainty that we only have to worry about NAT64 translators. We may also have NAT66 translators to consider. I'm not a supporter of this draft. -- james woodyatt member of technical staff, communications engineering From magnus.westerlund@ericsson.com Wed Mar 25 11:41: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 05F6F3A69B2 for ; Wed, 25 Mar 2009 11:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_SE=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 c2jxmQSEAwKX for ; Wed, 25 Mar 2009 11:41:15 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 311053A6849 for ; Wed, 25 Mar 2009 11:41:15 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6D0FC20C75; Wed, 25 Mar 2009 19:42:06 +0100 (CET) X-AuditID: c1b4fb3c-ac75cbb000003f6e-50-49ca7afe1983 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 43BC120BB1; Wed, 25 Mar 2009 19:42:06 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 19:42:06 +0100 Received: from [153.88.45.47] ([153.88.45.47]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 19:42:04 +0100 Message-ID: <49CA7AFC.9000803@ericsson.com> Date: Wed, 25 Mar 2009 11:42:04 -0700 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Charles E. Perkins" References: <499F1ED9.9010006@wichorus.com> In-Reply-To: <499F1ED9.9010006@wichorus.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Mar 2009 18:42:05.0108 (UTC) FILETIME=[64D4B740:01C9AD79] X-Brightmail-Tracker: AAAAAA== Cc: behave@ietf.org Subject: [BEHAVE] Comment regarding draft-perkins-sourceipnat-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, 25 Mar 2009 18:41:16 -0000 Hi, As I raised this comment on the mike I like to follow it up here. As this proposal has very similar properties to NAT-PT I think it is important that the document do addresses the relevant critique raised in RFC 4966 for this proposal and how it can mitigate the issue. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From marc.blanchet@viagenie.ca Wed Mar 25 11:46: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 9D6D13A69AA for ; Wed, 25 Mar 2009 11:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 Fw7FmcqolGDu for ; Wed, 25 Mar 2009 11:46:06 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 5F82E3A6D59 for ; Wed, 25 Mar 2009 11:46:05 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id C2C6529E1597; Wed, 25 Mar 2009 14:46:56 -0400 (EDT) Received: from dhcp-53fe.meeting.ietf.org (unknown [130.129.83.254]) by jazz.viagenie.ca (Postfix) with ESMTP id 345E629E156C; Wed, 25 Mar 2009 14:46:54 -0400 (EDT) Message-ID: <49CA7C1D.9030700@viagenie.ca> Date: Wed, 25 Mar 2009 11:46:53 -0700 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Charles E. Perkins" References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> In-Reply-To: <49CA7AFC.9000803@ericsson.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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, 25 Mar 2009 18:46:07 -0000 the question I had on the mike today: - given that the TTL of the name need to be low - what happens if I write a 2 line loop script which queries the name as fast and as many as I can? it would then create new mappings on the translator for each request. Therefore, end up pretty fast to allocate all ressources on the NAT. therefore, no more available until the timeouts start to happen, which can't be too short... How to mitigate that problem? Marc. -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From fred@cisco.com Wed Mar 25 12:04: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 118123A6B80 for ; Wed, 25 Mar 2009 12:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.428 X-Spam-Level: X-Spam-Status: No, score=-106.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LriWgIGhaRgS for ; Wed, 25 Mar 2009 12:04:15 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 065CA3A687F for ; Wed, 25 Mar 2009 12:04:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,420,1233532800"; d="scan'208";a="146579760" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2009 19:05:07 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2PJ575X016455; Wed, 25 Mar 2009 12:05:07 -0700 Received: from dhcp-56c8.meeting.ietf.org (sjc-vpn4-1206.cisco.com [10.21.84.181]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2PJ57iX002502; Wed, 25 Mar 2009 19:05:07 GMT Message-Id: From: Fred Baker To: Behave Chairs Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 12:05:06 -0700 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1680; t=1238007907; x=1238871907; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Plan=20for=20IPv4/IPv6=20translation=20document s |Sender:=20; bh=S5iA9xHVycwgtYUte8xKoS2zZeHZ5z35lRKNgSJv3lU=; b=yiP/3ueKpnGk6iplG1G9Nmd6W5Z0PJMY7/BI0BHDHOpvxxomIDrKfWJQI2 hOXDkSKq88mkfrne44VEO4YauhLXXfIi1r7Ou3jugTz51LFNNuED+g3haXAQ 9a+EsBWj55; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Behave WG Subject: [BEHAVE] Plan for IPv4/IPv6 translation 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: Wed, 25 Mar 2009 19:04:16 -0000 Referring to the October discussion and the chair's slides yesterday, and further to private email among the framework authors, the chairs, and Magnus yesterday and today, I want to capture what I understand to be the documentation plan. If I have it wrong, I would like to know that now; if I have it right I am already in process and want confirmation of the fact. One thing discussed privately is that the reference from the translation document to the prefix is normative, which means that the document referred to should be standards track. You asked me to pull the prefix into a separate document. So I understand that we have six documents called for at this point, with possible future ALG documents, for which I am suggesting appropriate monikers: IPv4/IPv6 Translation Framework Informational, based on draft-baker-behave-v4v6-framework-02.txt draft-ietf-behave-v4v6-framework-00.txt IPv4/IPv6 Translation Prefix recommendation Standards track, based on draft-baker-behave-v4v6-framework-02.txt draft-ietf-behave-v4v6-prefix-00.txt IP/ICMP Translation Standards track, based on draft-baker-behave-v4v6- translation-02.txt draft-ietf-behave-v4v6-translation-00.txt IPv4/IPv6 Stateful Translation Database Maintenance Standards track, based on draft-bagnulo-behave-nat64-03.txt draft-ietf-behave-v4v6-database-00.txt IPv4/IPv6 DNS Translation Database Algorithm and Gateway Standards track, based on draft-bagnulo-behave-dns64-02.txt draft-ietf-behave-v4v6-dns-00.txt IPv4/IPv6 FTP Application Layer Gateway Standards Track, to be determined Am I correct? From marcelo@it.uc3m.es Wed Mar 25 13:09: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 F23A73A6830 for ; Wed, 25 Mar 2009 13:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.644 X-Spam-Level: X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, 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 p8knvywrw9Q4 for ; Wed, 25 Mar 2009 13:09:07 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 25EFB3A63D2 for ; Wed, 25 Mar 2009 13:09:06 -0700 (PDT) Received: from dhcp-17e7.meeting.ietf.org (dhcp-17e7.meeting.ietf.org [130.129.23.231]) by smtp03.uc3m.es (Postfix) with ESMTP id 6F356731EC0; Wed, 25 Mar 2009 21:09:56 +0100 (CET) Message-ID: <49C8791E.3040408@it.uc3m.es> Date: Tue, 24 Mar 2009 07:09:34 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Magnus Westerlund References: <49C81A02.6090407@ericsson.com> In-Reply-To: <49C81A02.6090407@ericsson.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-5.6.0.1016-16542.000 Cc: Behave WG Subject: Re: [BEHAVE] Comment on draft-bagnulo-behave-nat64-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, 25 Mar 2009 20:09:08 -0000 makes sense to me, regards, marcelo Magnus Westerlund escribió: > Hi, > > A general comment on the document is that in most cases where the > solution isn't protocol specific the specification should be generic and > simply say transport protocol, instead of TCP or UDP. The transport > protocol specific parts already has its own section. > > The reason is that is should be clear what is protocol specific and what > is general procedures. Currently the document specifies TCP and UDP but > we have discussed extensions for DCCP and SCTP. To enable them to happen > the document needs this generality. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From magnus.westerlund@ericsson.com Wed Mar 25 14:50: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 3C15E28C0D6 for ; Wed, 25 Mar 2009 14:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_SE=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 eHnmXmWuzNdY for ; Wed, 25 Mar 2009 14:50:15 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4C38F3A6B3A for ; Wed, 25 Mar 2009 14:50:15 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BBDCC206B5; Wed, 25 Mar 2009 22:51:06 +0100 (CET) X-AuditID: c1b4fb3e-aa7b2bb000006d6d-ec-49caa74a16e7 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A057E20094; Wed, 25 Mar 2009 22:51:06 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 22:51:05 +0100 Received: from [153.88.47.84] ([153.88.47.84]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 22:51:05 +0100 Message-ID: <49CAA748.4060700@ericsson.com> Date: Wed, 25 Mar 2009 14:51:04 -0700 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fred Baker References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Mar 2009 21:51:05.0900 (UTC) FILETIME=[CC783EC0:01C9AD93] X-Brightmail-Tracker: AAAAAA== Cc: Behave WG , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Wed, 25 Mar 2009 21:50:16 -0000 Fred Baker skrev: > IPv4/IPv6 Stateful Translation Database Maintenance > Standards track, based on draft-bagnulo-behave-nat64-03.txt > draft-ietf-behave-v4v6-database-00.txt I think the Title of the this work is not consistent with what I would expect the document to consist of. It is not only the binding database, but also the actual translation that needs to be documented in this spec. > IPv4/IPv6 DNS Translation Database Algorithm and Gateway > Standards track, based on draft-bagnulo-behave-dns64-02.txt > draft-ietf-behave-v4v6-dns-00.txt Also in this case I wonder from where the words "Translation Database" is comming. -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fred@cisco.com Wed Mar 25 15:02: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 59ED328C101 for ; Wed, 25 Mar 2009 15:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.412 X-Spam-Level: X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZdUlEQ5yGaN for ; Wed, 25 Mar 2009 15:02:01 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0E1513A6C1D for ; Wed, 25 Mar 2009 15:02:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,422,1233532800"; d="scan'208";a="146793168" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2009 22:02:43 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2PM2egs024695; Wed, 25 Mar 2009 15:02:40 -0700 Received: from dhcp-56c8.meeting.ietf.org (sjc-vpn3-779.cisco.com [10.21.67.11]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2PM2e18011402; Wed, 25 Mar 2009 22:02:40 GMT Message-Id: <517C5943-7175-4BC8-9AB9-191DA6875FC2@cisco.com> From: Fred Baker To: Magnus Westerlund In-Reply-To: <49CAA748.4060700@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 15:02:39 -0700 References: <49CAA748.4060700@ericsson.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4550; t=1238018560; x=1238882560; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[BEHAVE]=20Plan=20for=20IPv4/IPv6=20tra nslation=20documents |Sender:=20; bh=gEbUlMKcXs6YyQS/OyW3U5L5TO4i1teJRranuujPyKo=; b=eX0m9BrjjRC4+jSxNsV/uqA0QfYRPeEQIXZQsNuLGT0sfD5Jvpc1k953+i 4CYU5jq83p1Lnw62wcv/n1OFSXBO9hYfQOxOnQ6mflmD77mbHUsNS7QJEugq /pipw2AK8X; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Behave WG , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Wed, 25 Mar 2009 22:02:02 -0000 On Mar 25, 2009, at 2:51 PM, Magnus Westerlund wrote: > Fred Baker skrev: > >> IPv4/IPv6 Stateful Translation Database Maintenance >> Standards track, based on draft-bagnulo-behave-nat64-03.txt >> draft-ietf-behave-v4v6-database-00.txt > > I think the Title of the this work is not consistent with what I would > expect the document to consist of. It is not only the binding > database, > but also the actual translation that needs to be documented in this > spec. It is already documented in the translation spec. Maybe you can tell me what needs to be specified there that isn't. What remains t be specified, and what I understood to be the topic of this document, is the issues of stateful translation that are not in the data path. I refer you to the text that reads Abstract 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 with neither state nor configuration 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. Significant issues exist in the stateless and stateful modes that are not addressed in this document, related to the address assignment and the maintenance of the translation tables, respectively. This document confines itself to the actual translation. ... I also refer you to the discussion in section 1.3, and the two bits of text regarding the actual translation: IPv4->IPv6: Source Address: The source address is derived from the IPv4 source address to form IPv4-embedded IPv6 address as specified in [I-D.baker-behave-v4v6-framework]. Destination Address: In stateless mode, which is to say that if the IPv4 destination address is within the range of the stateless translation prefix, the destination address is derived from the IPv4 destination address. In stateful mode, which is to say that if the IPv4 destination address is not within the range of the stateless translation prefix, the IPv4-related IPv6 address and corresponding transport layer destination port are derived from the database reflecting current session state in the translator. IPv6->IPv4: Source Address: In stateless mode, which is to say that if the IPv6 source address is within the range of the stateless translation prefix, the source address is derived from the IPv4-embedded IPv6 address. In stateful mode, which is to say that if the IPv6 source address is not within the range of the stateless translation prefix, the IPv4 source address and transport layer source port corresponding to the IPv4-related IPv6 source address and source port are derived from the database reflecting current session state in the translator. Destination Address: IPv6 packets that are translated have an IPv4- mapped destination address. Thus the address is derived from the IPv6 address as specified in [I-D.baker-behave-v4v6-framework]. Those are the only differences in the data path between stateful and stateless mode. >> IPv4/IPv6 DNS Translation Database Algorithm and Gateway >> Standards track, based on draft-bagnulo-behave-dns64-02.txt >> draft-ietf-behave-v4v6-dns-00.txt > > Also in this case I wonder from where the words "Translation Database" > is comming. The description of the "stateful" mode of translation implies the maintenance of dynamic state. That state is the correlation between IPv4 {address,port} tuples and IPv6 {address,port} tuples. The state database is where that is stored. Questions here relate to what data is there, how it gets into the database, how it gets removed from the database, and any issues that arise in the maintenance of the database. From fred@cisco.com Wed Mar 25 16:00: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 9880A28C216 for ; Wed, 25 Mar 2009 16:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.397 X-Spam-Level: X-Spam-Status: No, score=-106.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcPEJy+YiRg2 for ; Wed, 25 Mar 2009 16:00:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CE1403A6D9F for ; Wed, 25 Mar 2009 16:00:42 -0700 (PDT) X-Files: translation.c : 9562 X-IronPort-AV: E=Sophos;i="4.38,422,1233532800"; d="c'?scan'208";a="146700945" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2009 23:01:35 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2PN1Zsc025116; Wed, 25 Mar 2009 16:01:35 -0700 Received: from dhcp-56c8.meeting.ietf.org (sjc-vpn7-207.cisco.com [10.21.144.207]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2PN1ZeJ002105; Wed, 25 Mar 2009 23:01:35 GMT Message-Id: From: Fred Baker To: Magnus Westerlund In-Reply-To: <49CAA748.4060700@ericsson.com> Content-Type: multipart/mixed; boundary=Apple-Mail-10--130626048 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 16:01:35 -0700 References: <49CAA748.4060700@ericsson.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11516; t=1238022095; x=1238886095; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[BEHAVE]=20Plan=20for=20IPv4/IPv6=20tra nslation=20documents |Sender:=20; bh=WWmkyADyidK5CHuaMjtjYDlE2Y7YJlZSb1b5Gaaquv0=; b=f8w5c+V3NdocffcYfFv/YF2akSnmsKDJw+xd9phUNhwo24UoEw/O5EExMw WQy0SA9fhuU0iKItH7eobI63NEW3Sd/aqbriG5F7HuaAn6zEIFcZlfLOD4dJ /Xq0QTlTvClwyk4DiBvnCnT7KswwfNHYQCsSZydKwSzV6D3ZhT5+4=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Behave WG , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Wed, 25 Mar 2009 23:00:43 -0000 --Apple-Mail-10--130626048 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Coming back to the discussion you and I had yesterday, I sat down last night and wrote something that resembles C code but should probably be thought of as pseudocode in its present state. If folks think it has value, I could include this in the translation draft as a non- normative worked-example appendix. This big worry that I have with a separate specification for stateful and stateless translation in separate drafts is what my friends back at the ranch will do with them. At the point where some idiot looks at two potentially-incompatible specifications (read the translation draft and the NAT64 draft and ask yourself if you would automatically assume they are compatible) and decides that they need separate chips or (God help us) cards, and further decides that he'll do one in this release and one in the next, when what is needed is separate paths through and if-then-else conditional, the working group has fundamentally failed. And yes, I believe that this is possible; I know my guys back at the ranch and how they parse features. --Apple-Mail-10--130626048 Content-Disposition: attachment; filename=translation.c Content-Type: application/octet-stream; x-mac-creator=21526368; x-unix-mode=0644; x-mac-type=54455854; name="translation.c" Content-Transfer-Encoding: 7bit #define TCP 6 #define UDP 17 #define NULL_PORT (~0) typedef struct { unsigned version:4; unsigned header_length:4; unsigned tos:8; unsigned total_length:16; unsigned identification:16; unsigned flags:3; unsigned fragment_offset:13; unsigned ttl:8; unsigned protocol:8; unsigned header_checksum:16; unsigned char source[4]; unsigned char destination[4]; unsigned char options[0]; } IPv4Header; typedef struct { unsigned version:4; unsigned traffic_class:8; unsigned flow_label:20; unsigned payload_length:16; unsigned next_header:8; unsigned hop_limit:8; unsigned char source[16]; unsigned char destination[16]; } IPv6Header; /*********************************************************/ /* * magic routines * * these routines are specified by comment but are * not fleshed out in code. the reason is that what is inside them * is fairly obvious, and secondary to this discussion. */ /*********************************************************/ void drop_datagram () { /* * guess what this "routine" does... */ } /* * manipulate UDP/TCP header in an IPv6 datagram */ unsigned short extract_ipv6_source_port (v6) IPv6Header *v6; { /* * starting from IPv6 header, find UDP/TCP header. * return source port from UDP/TCP header */ } void apply_ipv6_destination_port (v6, port) IPv6Header *v6; unsigned short port; { /* * starting from IPv6 header, find UDP/TCP header. overwrite * destination port in UDP/TCP header. update the checksum. */ } /* * manipulate UDP/TCP header in an IPv4 datagram */ unsigned short extract_ipv4_destination_port (v4) IPv4Header *v4; { /* * starting from IPv4 header, find UDP/TCP header. return destination * port from UDP/TCP header */ } void apply_ipv4_source_port (v4, port) IPv4Header *v4; unsigned short port; { /* * starting from IPv4 header, find UDP/TCP header. overwrite * source port in UDP/TCP header. update the checksum. */ } void update_ipv6_transport_checksum (v6) IPv6Header *v6; { /* * find TCP or UDP checksum and update it according to the * changes between the IPv4 and IPv6 pseudoheader */ } void update_ipv4_transport_checksum (v4) IPv4Header *v4; { /* * find TCP or UDP checksum and update it according to the * changes between the IPv6 and IPv4 pseudoheader */ } /* * for stateful translation, manage dynamic address/port state * * the assumption is a dual index database or two databases. * we can search by {IPv4 address, port} or {ipv6 address, port}, * and as a result translate one to the other. */ boolean find_ipv6_for_ipv4 (v6, v4, v6_port, v4_port) IPv6Header *v6; IPv4Header *v4; unsigned short v4_port, *v6_port; { /* * using v4->destination and v4_port as indices, find dynamic state * if it exists. if it exists, return v6->destination, v6_port, and * TRUE. if it does not exist, return FALSE; */ } boolean find_ipv4_for_ipv6 (v4, v6, v4_port, v6_port) IPv6Header *v6; IPv4Header *v4; unsigned short *v4_port, v6_port; { /* * using v6->source and v6_port as indices, find dynamic state * if it exists. if it exists, return v6->destination, v6_port, and * TRUE. if it does not exist, return FALSE; */ } associate_ipv4_with_ipv6 (v4, v6, v4_port, v6_port) IPv6Header *v6; IPv4Header *v4; unsigned short v4_port, v6_port; { /* * create an association between IPv4 address/port and IPv6 * address/port. */ } disassociate_ipv4_from_ipv6 (v4, v6, v4_port, v6_port) IPv6Header *v6; IPv4Header *v4; unsigned short v4_port, v6_port; { /* * find an existing association between IPv4 address/port and IPv6 * address/port. if it is found, delete it. this is not called in * this prototype; one needs a background process to clean up aging * state. */ } boolean same_prefix (prefix, plength, address) unsigned char *prefix; unsigned short plength; unsigned char *address; { /* * if the first plength bits of prefix and address match, return TRUE; * * else return FALSE; */ } /*********************************************************/ /* * address translation routines * * This saves me from having to write the code multiple * times. Note that the use of bcopy in this limits the * location of the IPv4 prefix in the IPv6 prefix. Real code * would need to understand this and do the right thing in * the latter case.. */ /*********************************************************/ void stateless_translation_v4_to_v6_address (v4_address, v6_address, translation_prefix, offset) unsigned char *v4_address; unsigned char *v6_address; unsigned char *translation_prefix; unsigned short offset; { ASSERT (0 <= offset && offset <= 12); bcopy (translation_prefix, v6_address, 16); bcopy (v4_address, v6_address + offset, 4); } void stateless_translation_v6_to_v4_address (v6_address, v4_address, translation_prefix, offset) unsigned char *v4_address; unsigned char *v6_address; unsigned char *translation_prefix; unsigned short offset; { ASSERT (0 <= offset && offset <= 12); bcopy (v6_address + offset, v4_address, 4); } void stateful_translation_v4_to_v6_address (v4, v6) IPv6Header *v4; IPv4Header *v6; { unsigned short v4_port, v6_port; if (TCP == v4->protocol || UDP == v4->protocol) { extract_ipv4_destination_port (v4); if (find_ipv6_for_ipv4 (v6, v4, &v6_port, v4_port)) { apply_ipv6_destination_port (v6, v6_port); } else { drop_datagram (); } } else if (!find_ipv6_for_ipv4 (v6, v4, &v6_port, NULL_PORT)) { drop_datagram (); } } void stateful_translation_v6_to_v4_address (v6, v4) IPv6Header *v6; IPv4Header *v4; { unsigned short v4_port, v6_port; if (TCP == v4->protocol || UDP == v4->protocol) { extract_ipv6_destination_port (v6); if (find_ipv4_for_ipv6 (v4, v6, &v4_port, v6_port)) { apply_ipv4_destination_port (v4, v4_port); } else { associate_ipv4_with_ipv6 (v4, v6, &v4_port, v6_port); apply_ipv4_destination_port (v4, v4_port); } } else if (!find_ipv4_for_ipv6 (v4, v6, &v4_port, NULL_PORT)) { associate_ipv4_with_ipv6 (v4, v6, &v4_port, NULL_PORT); } } /*********************************************************/ /* * header translation routines * * this is the substance of the translation draft */ /*********************************************************/ void translate_ip4_to_ipv6 (v4, v6, overloaded_prefix) IPv6Header *v6; IPv4Header *v4; boolean overloaded_prefix; { v6->version = 6; v6->traffic_class = v4->tos; v6->flow_label = 0; v6->payload_length = v4->total_length - sizeof (IPv4Header) + sizeof (IPv6Header); v6->next_header = v4->protocol; v6->hop_limit = v4->ttl; if (overloaded_prefix) { stateful_translation_v4_to_v6_address (v4, v6); } else { stateless_translation_v4_to_v6_address (v4->destination, v6->destination, translation_prefix, offset); } stateless_translation_v4_to_v6_address (v4->source, v6->source, translation_prefix, offset); if (TCP == v6->protocol || UDP == v6->protocol) update_ipv6_transport_checksum (v6); } void translate_ip6_to_ipv4 (v6, v4) IPv6Header *v6; IPv4Header *v4; { v4->version = 4; v4->header_length = sizeof (IPv4Header) / 4; v4->tos = v6->traffic_class; v4->total_length = v6->payload_length - sizeof (IPv6Header) + sizeof (IPv4Header); v4->identification = magic_counter++; v4->flags = 0; v4->fragment_offset = 0; v4->ttl = v6->hop_limit; v4->protocol = v6->next_header; v4->header_checksum = 0; if (!same_prefix (translation_prefix, translation_prefix_length, v6->source)) { stateful_translation_v6_to_v4_address (v6, v4); } else { stateless_translation_v6_to_v4_address (v6->source, v4->source, translation_prefix, offset); } stateless_translation_v6_to_v4_address (v6->destination, v4->destination, translation_prefix, offset); v4->header_checksum = cksum (v4); if (TCP == v4->protocol || UDP == v4->protocol) update_ipv4_transport_checksum (v4); } --Apple-Mail-10--130626048 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-10--130626048-- From brian.e.carpenter@gmail.com Wed Mar 25 16:11: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 759CB28C216 for ; Wed, 25 Mar 2009 16:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, J_CHICKENPOX_13=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 rJ52-Zl4zpvr for ; Wed, 25 Mar 2009 16:11:57 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id CB5A128C21C for ; Wed, 25 Mar 2009 16:11:57 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so294003wfg.31 for ; Wed, 25 Mar 2009 16:12:50 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=p2EPcjqRfaFdjiFPLMWye15nmrmG07hc1xuRRYUSfxU=; b=IabDM/mtIDN8aqmSpGf13nDo+78/pCPQ5/yBqhsofO+wD0Bl2lYm8MzDeCa1XgniN7 xikJg9o/ndYEHY93bsaTYpI7Yw7S31m0rT6veNK+iFkq8OBGHwTLD+wPUAyQrbgB4xJ6 4zeY01uKYCW/5FI5EXlnlq7x/PbrF6f7WMaQU= 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:content-type:content-transfer-encoding; b=TjUpuA9et/7bMcGCvhGkLxrNYZIdznwpE2W4mttwYpefi4s84X4WvvTZYppCxcuZXY x++udlIBSKVltVm84+qpmVNN5xQ/XA292XyTmNMVfA/keMKG4yp/+TZqfKecvilITiG5 ZrQi61RchjSe58nkGzl9ReaoEQAACjqkfn4vI= Received: by 10.142.154.9 with SMTP id b9mr47278wfe.327.1238022770542; Wed, 25 Mar 2009 16:12:50 -0700 (PDT) Received: from ?130.129.18.229? (dhcp-12e5.meeting.ietf.org [130.129.18.229]) by mx.google.com with ESMTPS id 30sm16744700wff.7.2009.03.25.16.12.49 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Mar 2009 16:12:50 -0700 (PDT) Message-ID: <49CABA6C.4000906@gmail.com> Date: Thu, 26 Mar 2009 12:12:44 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-jiang-incremental-cgn@tools.ietf.org Subject: [BEHAVE] draft-jiang-incremental-cgn-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: Wed, 25 Mar 2009 23:11:58 -0000 This draft was discussed in v6ops, but the authors would be interested in comments from BEHAVE as well. We'll start working on the next version in a couple of weeks, so please comment soon. The slides are at http://www3.ietf.org/proceedings/09mar/slides/v6ops-7.pdf Brian From miyata@tahi.org Wed Mar 25 16:18: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 C23AF3A6DBE for ; Wed, 25 Mar 2009 16:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_33=0.6, J_CHICKENPOX_71=0.6, RDNS_DYNAMIC=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 OMbmpD6YW-cg for ; Wed, 25 Mar 2009 16:18:11 -0700 (PDT) Received: from ns.64translator.com (70.145.221.202.bf.2iij.net [202.221.145.70]) by core3.amsl.com (Postfix) with ESMTP id EB2EF3A6DC0 for ; Wed, 25 Mar 2009 16:17:53 -0700 (PDT) Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.14.2/8.14.2) with ESMTP id n2PNHRN3016329; Thu, 26 Mar 2009 08:17:27 +0900 (JST) (envelope-from miyata@tahi.org) Received: from [127.0.0.1] (fumi.64translator.com [10.21.254.6]) by bahamas.64translator.com (8.13.6/8.13.6) with ESMTP id n2PNHHhU026343; Thu, 26 Mar 2009 08:17:18 +0900 (JST) (envelope-from miyata@tahi.org) Message-Id: <67DFA2B0-AC2A-4E02-86B5-DDF30BB40CA1@tahi.org> From: Hiroshi MIYATA To: Fred Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Mar 2009 08:17:17 +0900 References: X-Mailer: Apple Mail (2.930.3) Cc: Behave WG , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Wed, 25 Mar 2009 23:18:11 -0000 Fred, I agree making separate prefix recommendation document, since we would have well known prefix for translator. WKP would work with some restriction, like IPv6 network to IPv4 internet. The document also need to describe the nature of PREFIX64(WKP and LIR) and limitation of usage. Yesterday meeting, I realized at least following items to be mentioned explicitly otherwise the users would face problems. - Context exchange w/ WKP + subnet bit We can not know the network topology of other site. So, when a node was informed synthetic address w/ subnet bit it would face problem, if it has only one nat64 box. To resolve this, the administrator needs to configure to lead all subnet bit to the only one nat64 box. - WKP is used only for IPv6 network to IPv4 internet - WKP MUST be concatenated with Global IPv4 address, otherwise referrals does not work well. If the private address is concatenated, it would make some problem. (When Private4a = Private4b = 10.0.0.0/8, it is difficult to distinguish) (IPv4 INTERNET) | | NAT NAT | | Private4a Private4b | | NAT64 NAT64 | | IPv6Net IPv6Net - WKP needs policy e.g., the routing information must not announced to outside. The ALG can inform the synthesized address with WKP or not. Some of them can be resolved by engineering in well managed environment, but in general it has some restriction. Which document we should based on is another discussion. ;-) Thanks, ....miyata On 2009/03/26, at 4:05, Fred Baker wrote: > Referring to the October discussion and the chair's slides > yesterday, and further to private email among the framework authors, > the chairs, and Magnus yesterday and today, I want to capture what I > understand to be the documentation plan. If I have it wrong, I would > like to know that now; if I have it right I am already in process > and want confirmation of the fact. > > One thing discussed privately is that the reference from the > translation document to the prefix is normative, which means that > the document referred to should be standards track. You asked me to > pull the prefix into a separate document. > > So I understand that we have six documents called for at this point, > with possible future ALG documents, for which I am suggesting > appropriate monikers: > > IPv4/IPv6 Translation Framework > Informational, based on draft-baker-behave-v4v6-framework-02.txt > draft-ietf-behave-v4v6-framework-00.txt > IPv4/IPv6 Translation Prefix recommendation > Standards track, based on draft-baker-behave-v4v6-framework-02.txt > draft-ietf-behave-v4v6-prefix-00.txt > IP/ICMP Translation > Standards track, based on draft-baker-behave-v4v6- > translation-02.txt > draft-ietf-behave-v4v6-translation-00.txt > IPv4/IPv6 Stateful Translation Database Maintenance > Standards track, based on draft-bagnulo-behave-nat64-03.txt > draft-ietf-behave-v4v6-database-00.txt > IPv4/IPv6 DNS Translation Database Algorithm and Gateway > Standards track, based on draft-bagnulo-behave-dns64-02.txt > draft-ietf-behave-v4v6-dns-00.txt > IPv4/IPv6 FTP Application Layer Gateway > Standards Track, to be determined > > Am I correct? > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From miyakawa@nttv6.jp Wed Mar 25 16:25: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 D25153A6988 for ; Wed, 25 Mar 2009 16:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 NJ9L+B6hi9I3 for ; Wed, 25 Mar 2009 16:25:44 -0700 (PDT) Received: from gura.nttv6.jp (gura.nttv6.jp [IPv6:2001:218:1f01:2::2]) by core3.amsl.com (Postfix) with ESMTP id F03433A680C for ; Wed, 25 Mar 2009 16:25:43 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 7B2A6BDC08; Thu, 26 Mar 2009 08:26:35 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 4AEE56FD83; Thu, 26 Mar 2009 08:26:35 +0900 (JST) Date: Thu, 26 Mar 2009 08:26:35 +0900 (JST) Message-Id: <20090326.082635.226707040.miyakawa@nttv6.jp> To: brian.e.carpenter@gmail.com From: Shin Miyakawa In-Reply-To: <49CABA6C.4000906@gmail.com> References: <49CABA6C.4000906@gmail.com> Organizaton: NTT Communications X-Mailer: Mew version 6.1 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: miyakawa@nttv6.jp, behave@ietf.org, draft-jiang-incremental-cgn@tools.ietf.org Subject: Re: [BEHAVE] draft-jiang-incremental-cgn-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: Wed, 25 Mar 2009 23:25:44 -0000 Brian, This looks simlar to a (potential) transition scheme I showed at IETF72 Technical prenaly. http://www.nttv6.jp/~miyakawa/IETF72/IETF-IAB-TECH-PLENARY-NTT-miyakawa.pdf My example uses NAT444 + Softwire to achieve the goal. Best wishes, Shin Miyakawa From Remi.Denis-Courmont@nokia.com Wed Mar 25 16:55: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 9E50428C171 for ; Wed, 25 Mar 2009 16:55:29 -0700 (PDT) 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.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 IQtAiLEENq2R for ; Wed, 25 Mar 2009 16:55:28 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 81DD63A6D9F for ; Wed, 25 Mar 2009 16:55:28 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2PNuCVf008604; Thu, 26 Mar 2009 01:56:15 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 01:56:14 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 01:56:14 +0200 Received: from leon.remlab.net (essapo-nirac252204.europe.nokia.com [10.162.252.204]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n2PNuCn2003035; Thu, 26 Mar 2009 01:56:12 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: behave@ietf.org Date: Thu, 26 Mar 2009 01:56:09 +0200 User-Agent: KMail/1.11.0 (Linux/2.6.28.9; KDE/4.2.0; i686; ; ) References: <57A37ACC-1E0A-42F1-A8B8-B06936F9F062@apple.com> In-Reply-To: <57A37ACC-1E0A-42F1-A8B8-B06936F9F062@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903260156.10567.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 25 Mar 2009 23:56:14.0196 (UTC) FILETIME=[47C34B40:01C9ADA5] X-Nokia-AV: Clean Subject: Re: [BEHAVE] comments draft-denis-behave-v4v6exthdr X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 23:55:29 -0000 On Wednesday 25 March 2009 20:27:21 ext james woodyatt wrote: > p1. As Dave Thaler argued, there may be multiple legacy NAT44s in the > path from any particular IPv4 source to an IPv6 destination, and the > utility of the information inserted by a NAT64 with this extension > header for making address referrals to other IPv4-translated peers of > an IPv6 node is therefore basically epsilon. Hmm. I for one do not think that putting a NAT64 behind a legacy NAT is suc= h a=20 great idea. Of course, it will sometime happen. I just wonder how frequent= =20 that will be. At least, that's an easy to detect failure mode (this is=20 documented already). Additionnaly, the option does let the application know= =20 that the flow is being protocol-translated, independent of NAT44. > p2. I think it may be premature to take up this work for another > reason. Until the 6AI controversy is concluded, I think we cannot yet > say with certainty that we only have to worry about NAT64 > translators. We may also have NAT66 translators to consider. You have a point. That being said, it would be fairly trivial to extend it = to=20 support NAT66, if it is specified, and would make a lot of sense. In fact, = in=20 that case, the nested legacy NAT problem is non-existent. I admit I did not= =20 imagine the IETF would consider NAT66 when I initially wrote the original=20 document. However, I am unclear whether you're against the document ever, or against = the=20 document now... ? =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From jhw@apple.com Wed Mar 25 17:24: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 319E23A6A10 for ; Wed, 25 Mar 2009 17:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.014 X-Spam-Level: X-Spam-Status: No, score=-106.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUxLEiooU5a6 for ; Wed, 25 Mar 2009 17:24:09 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 7C6093A6805 for ; Wed, 25 Mar 2009 17:24:09 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 7F2BC58E16DB for ; Wed, 25 Mar 2009 17:25:02 -0700 (PDT) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Brightmail Gateway) with ESMTP id 656E3280A3 for ; Wed, 25 Mar 2009 17:25:02 -0700 (PDT) X-AuditID: 11807134-a985dbb000000ff0-44-49cacb5e7260 Received: from [17.151.77.40] (unknown [17.151.77.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay14.apple.com (Apple SCV relay) with ESMTP id 472E528094 for ; Wed, 25 Mar 2009 17:25:02 -0700 (PDT) Message-Id: <25DE2E48-9D3A-41D9-A497-18165C885652@apple.com> From: james woodyatt To: "behave@ietf.org WG" In-Reply-To: <200903260156.10567.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 17:25:01 -0700 References: <57A37ACC-1E0A-42F1-A8B8-B06936F9F062@apple.com> <200903260156.10567.remi.denis-courmont@nokia.com> X-Mailer: Apple Mail (2.930.3) X-Brightmail-Tracker: AAAAAA== Subject: Re: [BEHAVE] comments draft-denis-behave-v4v6exthdr X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2009 00:24:10 -0000 On Mar 25, 2009, at 16:56, R=E9mi Denis-Courmont wrote: > > However, I am unclear whether you're against the document ever, or =20 > against the document now... ? I'd like to see the 6AI controversy resolved before considering this =20 proposal. If 6AI results in NAT66 becoming a permanent fixture of the =20= Internet, then I'd like to see a substantially different version of =20 this proposal aimed at helping with address referrals in the presence =20= of both NAT66 and NAT64. On the other hand, if 6AI fails to make =20 NAT66 into a permanent fixture of the Internet, then whatever shim-and-=20= tunnel solution we need to come up with to satisfy the open problems =20 that 6AI is facing may in fact be adaptable as a coex64 mechanism if =20 we play our cards right. Summary: I'm against the document now. I might change my mind later =20 as the situation evolves, though I suspect that if I *do* ever come =20 around, it will be too late to do so. -- james woodyatt member of technical staff, communications engineering From magnus.westerlund@ericsson.com Wed Mar 25 19:01: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 E49B628C282 for ; Wed, 25 Mar 2009 19:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_SE=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 N4V01dUDOIRi for ; Wed, 25 Mar 2009 19:01:39 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6F51A28C281 for ; Wed, 25 Mar 2009 19:01:38 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 796432100C; Thu, 26 Mar 2009 03:02:18 +0100 (CET) X-AuditID: c1b4fb3c-adf5fbb000003f6e-f4-49cae22af57f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4382A204AD; Thu, 26 Mar 2009 03:02:18 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 03:02:18 +0100 Received: from [153.88.47.84] ([153.88.47.84]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 03:02:16 +0100 Message-ID: <49CAE227.7050304@ericsson.com> Date: Wed, 25 Mar 2009 19:02:15 -0700 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fred Baker References: <49CAA748.4060700@ericsson.com> <517C5943-7175-4BC8-9AB9-191DA6875FC2@cisco.com> In-Reply-To: <517C5943-7175-4BC8-9AB9-191DA6875FC2@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Mar 2009 02:02:17.0020 (UTC) FILETIME=[E38EA7C0:01C9ADB6] X-Brightmail-Tracker: AAAAAA== Cc: Behave WG , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Thu, 26 Mar 2009 02:01:40 -0000 Fred, Okay, I totally have missed the reference to statefull in the SIIT update. I don't think the SIIT document covers all the parts necessary for stateful translation. There are additional considerations due to the port overloading. Thus the requirements that exist for NAT44 do apply to this type of stateful translation. In my view it is not simply handling state that is necessary in the stateful translator document. The suggested title seems very restricted. Are you suggesting that we expand the SIIT update document to contain all the stateful packet translation rules? Regards Magnus Fred Baker skrev: > > On Mar 25, 2009, at 2:51 PM, Magnus Westerlund wrote: > >> Fred Baker skrev: >> >>> IPv4/IPv6 Stateful Translation Database Maintenance >>> Standards track, based on draft-bagnulo-behave-nat64-03.txt >>> draft-ietf-behave-v4v6-database-00.txt >> >> I think the Title of the this work is not consistent with what I would >> expect the document to consist of. It is not only the binding database, >> but also the actual translation that needs to be documented in this spec. > > It is already documented in the translation spec. Maybe you can tell me > what needs to be specified there that isn't. What remains t be > specified, and what I understood to be the topic of this document, is > the issues of stateful translation that are not in the data path. > > I refer you to the text that reads > > Abstract > > 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 with neither state nor configuration 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. > > Significant issues exist in the stateless and stateful modes that are > not addressed in this document, related to the address assignment and > the maintenance of the translation tables, respectively. This > document confines itself to the actual translation. > ... > > I also refer you to the discussion in section 1.3, and the two bits of > text regarding the actual translation: > > IPv4->IPv6: > Source Address: The source address is derived from the IPv4 source > address to form IPv4-embedded IPv6 address as specified in > [I-D.baker-behave-v4v6-framework]. > > Destination Address: In stateless mode, which is to say that if the > IPv4 destination address is within the range of the stateless > translation prefix, the destination address is derived from the > IPv4 destination address. > > In stateful mode, which is to say that if the IPv4 destination > address is not within the range of the stateless translation > prefix, the IPv4-related IPv6 address and corresponding transport > layer destination port are derived from the database reflecting > current session state in the translator. > > IPv6->IPv4: > Source Address: In stateless mode, which is to say that if the IPv6 > source address is within the range of the stateless translation > prefix, the source address is derived from the IPv4-embedded IPv6 > address. > > In stateful mode, which is to say that if the IPv6 source address > is not within the range of the stateless translation prefix, the > IPv4 source address and transport layer source port corresponding > to the IPv4-related IPv6 source address and source port are > derived from the database reflecting current session state in the > translator. > > Destination Address: IPv6 packets that are translated have an IPv4- > mapped destination address. Thus the address is derived from the > IPv6 address as specified in [I-D.baker-behave-v4v6-framework]. > > Those are the only differences in the data path between stateful and > stateless mode. > >>> IPv4/IPv6 DNS Translation Database Algorithm and Gateway >>> Standards track, based on draft-bagnulo-behave-dns64-02.txt >>> draft-ietf-behave-v4v6-dns-00.txt >> >> Also in this case I wonder from where the words "Translation Database" >> is comming. > > The description of the "stateful" mode of translation implies the > maintenance of dynamic state. That state is the correlation between IPv4 > {address,port} tuples and IPv6 {address,port} tuples. The state database > is where that is stored. Questions here relate to what data is there, > how it gets into the database, how it gets removed from the database, > and any issues that arise in the maintenance of the database. > > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From marcelo@it.uc3m.es Wed Mar 25 19:09: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 339213A6A26 for ; Wed, 25 Mar 2009 19:09:08 -0700 (PDT) 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 Pa9HTFLYDrc4 for ; Wed, 25 Mar 2009 19:09:07 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 3883E3A6A10 for ; Wed, 25 Mar 2009 19:09:06 -0700 (PDT) Received: from dhcp-17e7.meeting.ietf.org (dhcp-17e7.meeting.ietf.org [130.129.23.231]) by smtp01.uc3m.es (Postfix) with ESMTP id 284C0BA505C; Thu, 26 Mar 2009 03:09:56 +0100 (CET) Message-ID: <49CAE3EE.1080908@it.uc3m.es> Date: Thu, 26 Mar 2009 03:09:50 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Magnus Westerlund References: <49CAA748.4060700@ericsson.com> In-Reply-To: <49CAA748.4060700@ericsson.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-5.6.0.1016-16542.003 Cc: Behave WG , Fred Baker , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Thu, 26 Mar 2009 02:09:08 -0000 Magnus Westerlund escribió: > Fred Baker skrev: > > >> IPv4/IPv6 Stateful Translation Database Maintenance >> Standards track, based on draft-bagnulo-behave-nat64-03.txt >> draft-ietf-behave-v4v6-database-00.txt >> > > I think the Title of the this work is not consistent with what I would > expect the document to consist of. It is not only the binding database, > but also the actual translation that needs to be documented in this spec. > > > my take on this is that the nat64 draft would rely in the statefull draft in the same way natpt relied on SIIIT. Regards, marcelo >> IPv4/IPv6 DNS Translation Database Algorithm and Gateway >> Standards track, based on draft-bagnulo-behave-dns64-02.txt >> draft-ietf-behave-v4v6-dns-00.txt >> > > Also in this case I wonder from where the words "Translation Database" > is comming. > > > > From fred@cisco.com Wed Mar 25 19:27: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 48F6128C22B for ; Wed, 25 Mar 2009 19:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.401 X-Spam-Level: X-Spam-Status: No, score=-106.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULFnkvWKv+9p for ; Wed, 25 Mar 2009 19:27:12 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8347B3A69D3 for ; Wed, 25 Mar 2009 19:27:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,422,1233532800"; d="scan'208";a="161759980" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Mar 2009 02:28:05 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2Q2S5tb014968; Wed, 25 Mar 2009 19:28:05 -0700 Received: from dhcp-56c8.meeting.ietf.org (sjc-vpn3-1087.cisco.com [10.21.68.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2Q2S4UH028763; Thu, 26 Mar 2009 02:28:05 GMT Message-Id: <13697CF7-2261-41E3-BED5-2ABD45168B5D@cisco.com> From: Fred Baker To: Magnus Westerlund , MARCELO BAGNULO BRAUN In-Reply-To: <49CAE227.7050304@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 19:26:44 -0700 References: <49CAA748.4060700@ericsson.com> <517C5943-7175-4BC8-9AB9-191DA6875FC2@cisco.com> <49CAE227.7050304@ericsson.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1024; t=1238034485; x=1238898485; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[BEHAVE]=20Plan=20for=20IPv4/IPv6=20tra nslation=20documents |Sender:=20; bh=DAkIKgc8ItQPYS/ZLeASsbxTy8ZlgH/MuZCg9+g8Gbo=; b=nW/KyIk3lFxh2HqICREfccehMrClkiyvYUggYhHP304DIn0BUflmcMHYF7 eJ/Hp6bOcbUnsXjtLHXkxT3eWrceB8fbXJxBP1FynLjj0NCgvlEanFl0OM+t CRgHXY8t8V; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Behave WG , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Thu, 26 Mar 2009 02:27:13 -0000 On Mar 25, 2009, at 7:02 PM, Magnus Westerlund wrote: > Okay, I totally have missed the reference to statefull in the SIIT > update. I don't think the SIIT document covers all the parts necessary > for stateful translation. There are additional considerations due to > the > port overloading. Thus the requirements that exist for NAT44 do > apply to > this type of stateful translation. > > In my view it is not simply handling state that is necessary in the > stateful translator document. The suggested title seems very > restricted. > > Are you suggesting that we expand the SIIT update document to contain > all the stateful packet translation rules? On Mar 25, 2009, at 7:09 PM, marcelo bagnulo braun wrote: > my take on this is that the nat64 draft would rely in the statefull > draft in the same way natpt relied on SIIIT. Marcelo, maybe you could comment in more detail here. What do you see the division as? In what way would you like to build on the translation draft? From xing@cernet.edu.cn Wed Mar 25 21:52: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 5DC313A6DD3 for ; Wed, 25 Mar 2009 21:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 PPSPARA4rhE7 for ; Wed, 25 Mar 2009 21:52:50 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 1659B3A6BA2 for ; Wed, 25 Mar 2009 21:52:46 -0700 (PDT) Received: from [127.0.0.1]([59.66.24.119]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm549cb36c1; Thu, 26 Mar 2009 12:53:37 +0800 Message-ID: <49CB0A2F.7010801@cernet.edu.cn> Date: Thu, 26 Mar 2009 12:53:03 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fred Baker 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: 4LzahmVB Cc: Behave WG , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Thu, 26 Mar 2009 04:52:51 -0000 Fred Baker 写é“: > Referring to the October discussion and the chair's slides yesterday, > and further to private email among the framework authors, the chairs, > and Magnus yesterday and today, I want to capture what I understand to > be the documentation plan. If I have it wrong, I would like to know > that now; if I have it right I am already in process and want > confirmation of the fact. > > One thing discussed privately is that the reference from the > translation document to the prefix is normative, which means that the > document referred to should be standards track. You asked me to pull > the prefix into a separate document. > > So I understand that we have six documents called for at this point, > with possible future ALG documents, for which I am suggesting > appropriate monikers: > > IPv4/IPv6 Translation Framework > Informational, based on draft-baker-behave-v4v6-framework-02.txt > draft-ietf-behave-v4v6-framework-00.txt > IPv4/IPv6 Translation Prefix recommendation > Standards track, based on draft-baker-behave-v4v6-framework-02.txt > draft-ietf-behave-v4v6-prefix-00.txt > IP/ICMP Translation > Standards track, based on draft-baker-behave-v4v6-translation-02.txt > draft-ietf-behave-v4v6-translation-00.txt > IPv4/IPv6 Stateful Translation Database Maintenance > Standards track, based on draft-bagnulo-behave-nat64-03.txt > draft-ietf-behave-v4v6-database-00.txt > IPv4/IPv6 DNS Translation Database Algorithm and Gateway > Standards track, based on draft-bagnulo-behave-dns64-02.txt > draft-ietf-behave-v4v6-dns-00.txt > IPv4/IPv6 FTP Application Layer Gateway > Standards Track, to be determined > > Am I correct? > Yes, this is our understanding. xing > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From Fred.L.Templin@boeing.com Wed Mar 25 22:57: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 B23DC3A6DEF for ; Wed, 25 Mar 2009 22:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.983 X-Spam-Level: X-Spam-Status: No, score=-5.983 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, J_CHICKENPOX_13=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 8M8t6rLbcThu for ; Wed, 25 Mar 2009 22:57:02 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id DD62B3A6B12 for ; Wed, 25 Mar 2009 22:57:02 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2Q5vj7i011202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Mar 2009 22:57:46 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2Q5vjhF010676; Thu, 26 Mar 2009 00:57:45 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2Q5vjGt010665; Thu, 26 Mar 2009 00:57:45 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 22:57:45 -0700 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, 25 Mar 2009 22:57:43 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105BB5267@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <49CABA6C.4000906@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-jiang-incremental-cgn-00.txt Thread-Index: Acmtn0EvGxgcGCRRQay1nxItAWoG7QALm0vw References: <49CABA6C.4000906@gmail.com> From: "Templin, Fred L" To: "Brian E Carpenter" , "Behave WG" X-OriginalArrivalTime: 26 Mar 2009 05:57:45.0136 (UTC) FILETIME=[C8921300:01C9ADD7] Cc: draft-jiang-incremental-cgn@tools.ietf.org Subject: [BEHAVE] Comments on draft-jiang-incremental-cgn-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, 26 Mar 2009 05:57:03 -0000 This document appears to be in very good shape for a -00 draft, and I have only one observation for now. In Section 3, the sentence: "...NAT-PT [RFC2766, RFC4966] (or its replacement) can be integrated with CGN." - I am wondering here whether a NAT-PT or equivalent function could also reside within the Dual-Stack Home Gateway (HG) such that the state maintenance, DNS, fate sharing, etc. is kept close to the hosts? Then, let the CGN become a dual-stack IPv6 router, and the ISP network can be traversed via an IPv6/IPv4 tunnel. Consider also that tunnels could go from HG(A) to HG(B) within the same ISP network. Only the HGs and CGNs are touched while the ISP network can remain as IPv4, so the scenario begins to look very much like VET. In this sort of arrangement, for an IPv4-only host in the home network connecting to an IPv4 server in the Internet, the HG just lets it go as IPv4 using NAT44. For an IPv4-only host connecting to an IPv6 server, however, the HG's NAT-PT function (or equivalent) would establish the necessary state such that IPv4 packets going out are translated to IPv6, and IPv6 packets coming in are translated to IPv4. For an IPv6-only host in the home network connecting to an IPv6 server, the HG just lets it go as IPv6, tunneled over IPv4 in the ISP network if necessary. For an IPv6-only host connecting to an IPv4 server, however, discover the server's address ('a.b.c.d') and map it to a special-use IPv6 /96 prefix, e.g., as "f00::a.b.c.d/96". Let the CGN advertise reachability to "f00::/96" such that the HG's IPv6 packets are conveyed to the CGN. The CGN then translates the IPv6 packets going out into IPv4 packets, and uses NAT44 to forward them on to the IPv4 server (with IPv4-to-IPv6 translation in the reverse path). In this sense, "f00::/96" represents the entire IPv4 Internet. So, there are two seperate and complimentary NAT-PT (or equivalent) functions - one in the HG and one in the CGN - but each presents a slightly different service model as described above. Is this something like what you had in mind? Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Wednesday, March 25, 2009 4:13 PM > To: Behave WG > Cc: draft-jiang-incremental-cgn@tools.ietf.org > Subject: [BEHAVE] draft-jiang-incremental-cgn-00.txt >=20 > This draft was discussed in v6ops, but the authors would be interested > in comments from BEHAVE as well. We'll start working on the next version > in a couple of weeks, so please comment soon. >=20 > The slides are at > http://www3.ietf.org/proceedings/09mar/slides/v6ops-7.pdf >=20 > Brian > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From pierre.levis@orange-ftgroup.com Thu Mar 26 06:16: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 303463A683D; Thu, 26 Mar 2009 06:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.026 X-Spam-Level: X-Spam-Status: No, score=-3.026 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 mGWOP+0rqxnq; Thu, 26 Mar 2009 06:16:11 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id EBAA03A67A8; Thu, 26 Mar 2009 06:16:10 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 14:17:02 +0100 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: Thu, 26 Mar 2009 14:16:56 +0100 Message-ID: In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D02D5CE0A@SGSINSMBS02.ad4.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Layer2-Aware NAT (draft-miles-behave-l2nat-00) Thread-Index: AcmgdlhcsqF9XOaRSFmUv5LfTG7d5QAAEU/wA2dPQ2A= References: <986DCE2E44129444B6435ABE8C9E424D02D5CE0A@SGSINSMBS02.ad4.ad.alcatel.com> From: To: , X-OriginalArrivalTime: 26 Mar 2009 13:17:02.0255 (UTC) FILETIME=[26A343F0:01C9AE15] Subject: [BEHAVE] Follow up on Layer2-Aware NAT (draft-miles-behave-l2nat-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, 26 Mar 2009 13:16:12 -0000 The comment I had on the mike during behave session 2: This kind of work is very valuable, it is worth not only for CGN but also for Port Ranges solutions and for all IPv4 shortage solutions.=20 As we presented it in the shara BoF all solutions basically: 1) Put a dedicated function in an ISP Box (CGN, PRR, whatever) 2) Use some sort of transport mechanism (tunneling, layer 2, whatever) between customers and ISPBox,=20 3) Are confronted with the same issues: how to force a route from customers to ISPBox, how to route back from ISPBox to relevant customer, how to identify the customer.=20 This would advocate for seeing all work related to IPv4 shared addresses host in the same place, under the same ombrella. =20 Regards Pierre From pierre.levis@orange-ftgroup.com Thu Mar 26 06:28: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 0F1E73A68B2 for ; Thu, 26 Mar 2009 06:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.032, 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 OQOFu9Xaj0pZ for ; Thu, 26 Mar 2009 06:28:30 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id B14E83A6829 for ; Thu, 26 Mar 2009 06:28:29 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 14:29:19 +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, 26 Mar 2009 14:29:14 +0100 Message-ID: In-Reply-To: <49CA7C1D.9030700@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] DOS regarding draft-perkins-sourceipnat-00 Thread-Index: Acmtehf4uzZd1RB1STCI/ik6od0gjAAm1OsA References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> From: To: , X-OriginalArrivalTime: 26 Mar 2009 13:29:19.0657 (UTC) FILETIME=[DE29E190:01C9AE16] Cc: behave@ietf.org Subject: Re: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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, 26 Mar 2009 13:28:31 -0000 If I've understood well, there is also a possibility to directly attack = the IPv4 address pool. Assuming an attacker knows this pool, he can generate packets (with = different source addresses) towards this pool, and hence eat most of the = pending mappings before the real packets arrive. It will be diffcult to = filter because the NAT does not know what source addresses are = legitimate. Pierre -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de Marc Blanchet Envoy=E9 : mercredi 25 mars 2009 19:47 =C0 : Charles E. Perkins Cc : behave@ietf.org Objet : [BEHAVE] DOS regarding draft-perkins-sourceipnat-00 the question I had on the mike today: - given that the TTL of the name need to be low - what happens if I write a 2 line loop script which queries the name as fast and as many as I can? it would then create new mappings on the translator for each request. Therefore, end up pretty fast to allocate all ressources on the NAT. therefore, no more available until the timeouts start to happen, which can't be too short... How to mitigate that problem? Marc. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From xing@cernet.edu.cn Thu Mar 26 06: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 B4CB43A689B for ; Thu, 26 Mar 2009 06:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[AWL=-0.937, 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 aU4rpYo6+yan for ; Thu, 26 Mar 2009 06:39:38 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id D6D0B3A6884 for ; Thu, 26 Mar 2009 06:39:35 -0700 (PDT) Received: from [127.0.0.1]([123.112.68.59]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmc49cbb239; Thu, 26 Mar 2009 21:40:26 +0800 Message-ID: <49CB85A9.6090903@cernet.edu.cn> Date: Thu, 26 Mar 2009 21:39:53 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hiroshi MIYATA References: <67DFA2B0-AC2A-4E02-86B5-DDF30BB40CA1@tahi.org> In-Reply-To: <67DFA2B0-AC2A-4E02-86B5-DDF30BB40CA1@tahi.org> 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: 4doopmVB Cc: Behave WG , Fred Baker , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Thu, 26 Mar 2009 13:39:38 -0000 Hiroshi MIYATA 写é“: > Fred, > > I agree making separate prefix recommendation document, since we would > have well known > prefix for translator. > WKP would work with some restriction, like IPv6 network to IPv4 internet. For the stateless translator, the LIR is the only choice since we should not insert the global IPv4 routing table into global IPv6 routing system. > > > Which document we should based on is another discussion. ;-) > In the draft-baker-behave-v4v6-framework-02.txt, it summarizes both the stateless and the stateful modes of the translator, while the others only address the stateful mode. xing From brian.e.carpenter@gmail.com Thu Mar 26 07:38: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 39C4228C0F1 for ; Thu, 26 Mar 2009 07:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, J_CHICKENPOX_13=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 NHB0H7Mg2tO1 for ; Thu, 26 Mar 2009 07:38:34 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 5AFA63A6A4F for ; Thu, 26 Mar 2009 07:38:34 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so714092wfg.31 for ; Thu, 26 Mar 2009 07:39:27 -0700 (PDT) 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=3OAWNiH6ozce25p3ErwXnbzmzqN4hSjOOPXl7qIFu18=; b=jxct/IMivYb4sE+E86hB04bDYf7nUtIwDempMv50i13cpSS+qWDvy4NHW7WtacSZGZ fRH9BEtJ8l/WmgDj5mt781E3TDlMNEar8OO274CMzWl0QI+mEVLshu8zT3HXAfs9kavI 64+WMkGSlYO7ZtD9Oidk1jKHgWbPfVS60j1Mo= 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=dZsh9UU4BjHi0+PjftieBnX5hKnyY8G2FLfGJHq3ITEpPXL/KANARX+rZxcm4Bh4a1 TbVKZXjwNO/uW7T5GIJ+0K8n4XA2qPIntib0VwcnWGwselFOX9ziAF/Cor3F6tPQ1K/B wr19cuDD2LQRYljK29bQAqsCkbEz8H3wboS8c= Received: by 10.142.89.13 with SMTP id m13mr409804wfb.50.1238078367631; Thu, 26 Mar 2009 07:39:27 -0700 (PDT) Received: from ?130.129.64.245? (dhcp-40f5.meeting.ietf.org [130.129.64.245]) by mx.google.com with ESMTPS id 30sm408490wfa.38.2009.03.26.07.39.26 (version=SSLv3 cipher=RC4-MD5); Thu, 26 Mar 2009 07:39:27 -0700 (PDT) Message-ID: <49CB9397.5090909@gmail.com> Date: Fri, 27 Mar 2009 03:39:19 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" References: <49CABA6C.4000906@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A105BB5267@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105BB5267@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Behave WG , draft-jiang-incremental-cgn@tools.ietf.org Subject: Re: [BEHAVE] Comments on draft-jiang-incremental-cgn-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, 26 Mar 2009 14:38:35 -0000 Fred, Thanks for your comment. I think placement of NAT64 functions will be an interesting discussion - essentially you seem to be suggesting that in the 'IPv4 network connects to IPv6 Internet' scenario, the IPv4 network is limited to whatever is behind an individual CPE. That does appear to have a scaling advantage, but on the other hand it's a lot of extra logic to be shoved inside a $99 CPE. Brian On 2009-03-26 18:57, Templin, Fred L wrote: > This document appears to be in very good shape for a > -00 draft, and I have only one observation for now. In > Section 3, the sentence: "...NAT-PT [RFC2766, RFC4966] > (or its replacement) can be integrated with CGN." - I > am wondering here whether a NAT-PT or equivalent > function could also reside within the Dual-Stack > Home Gateway (HG) such that the state maintenance, > DNS, fate sharing, etc. is kept close to the hosts? > > Then, let the CGN become a dual-stack IPv6 router, and > the ISP network can be traversed via an IPv6/IPv4 tunnel. > Consider also that tunnels could go from HG(A) to HG(B) > within the same ISP network. Only the HGs and CGNs > are touched while the ISP network can remain as IPv4, > so the scenario begins to look very much like VET. > > In this sort of arrangement, for an IPv4-only host in > the home network connecting to an IPv4 server in the > Internet, the HG just lets it go as IPv4 using NAT44. > For an IPv4-only host connecting to an IPv6 server, > however, the HG's NAT-PT function (or equivalent) would > establish the necessary state such that IPv4 packets > going out are translated to IPv6, and IPv6 packets > coming in are translated to IPv4. > > For an IPv6-only host in the home network connecting > to an IPv6 server, the HG just lets it go as IPv6, > tunneled over IPv4 in the ISP network if necessary. > For an IPv6-only host connecting to an IPv4 server, > however, discover the server's address ('a.b.c.d') > and map it to a special-use IPv6 /96 prefix, e.g., as > "f00::a.b.c.d/96". Let the CGN advertise reachability > to "f00::/96" such that the HG's IPv6 packets are > conveyed to the CGN. The CGN then translates the > IPv6 packets going out into IPv4 packets, and uses > NAT44 to forward them on to the IPv4 server (with > IPv4-to-IPv6 translation in the reverse path). In > this sense, "f00::/96" represents the entire IPv4 > Internet. > > So, there are two seperate and complimentary NAT-PT > (or equivalent) functions - one in the HG and one in > the CGN - but each presents a slightly different > service model as described above. Is this something > like what you had in mind? > > Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Wednesday, March 25, 2009 4:13 PM >> To: Behave WG >> Cc: draft-jiang-incremental-cgn@tools.ietf.org >> Subject: [BEHAVE] draft-jiang-incremental-cgn-00.txt >> >> This draft was discussed in v6ops, but the authors would be interested >> in comments from BEHAVE as well. We'll start working on the next > version >> in a couple of weeks, so please comment soon. >> >> The slides are at >> http://www3.ietf.org/proceedings/09mar/slides/v6ops-7.pdf >> >> Brian >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > From marcelo@it.uc3m.es Thu Mar 26 07:54: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 AC8663A6A4F for ; Thu, 26 Mar 2009 07:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 jd4ws+oO-t7N for ; Thu, 26 Mar 2009 07:54:42 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CE4E43A6858 for ; Thu, 26 Mar 2009 07:54:41 -0700 (PDT) Received: from dhcp-17e7.meeting.ietf.org (dhcp-17e7.meeting.ietf.org [130.129.23.231]) by smtp02.uc3m.es (Postfix) with ESMTP id 4EE80656BB8; Thu, 26 Mar 2009 15:55:32 +0100 (CET) Message-ID: <49CB9763.4060705@it.uc3m.es> Date: Thu, 26 Mar 2009 15:55:31 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Xing Li References: <67DFA2B0-AC2A-4E02-86B5-DDF30BB40CA1@tahi.org> <49CB85A9.6090903@cernet.edu.cn> In-Reply-To: <49CB85A9.6090903@cernet.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16544.000 Cc: Behave WG , Hiroshi MIYATA , Fred Baker , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Thu, 26 Mar 2009 14:54:42 -0000 Xing Li escribiĂł: > Hiroshi MIYATA 写é“: >> Fred, >> >> I agree making separate prefix recommendation document, since we >> would have well known >> prefix for translator. >> WKP would work with some restriction, like IPv6 network to IPv4 >> internet. > > For the stateless translator, the LIR is the only choice since we > should not insert the global IPv4 routing table into global IPv6 > routing system. > imho this problem is not related to stateless or statefull, but related to whether the scenario involves an IPv6 network or the IPv6 Internet (i.e. by definition, you cannot inject the IPv4 routing table into the IPv6 internet if the scenarion does not involves the IPv6 internet) regards, marcelo >> >> >> Which document we should based on is another discussion. ;-) >> > In the draft-baker-behave-v4v6-framework-02.txt, it summarizes both > the stateless and the stateful modes of the translator, while the > others only address the stateful mode. > > xing > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From Fred.L.Templin@boeing.com Thu Mar 26 09:00: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 1BD3D3A6DFF for ; Thu, 26 Mar 2009 09:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.984 X-Spam-Level: X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, J_CHICKENPOX_13=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 klO52gkjFOeA for ; Thu, 26 Mar 2009 09:00:18 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 1FA203A6B57 for ; Thu, 26 Mar 2009 09:00:18 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2QG189c012614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Mar 2009 09:01:08 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2QG17DW007450; Thu, 26 Mar 2009 11:01:07 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2QG13vA007322; Thu, 26 Mar 2009 11:01:07 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 09:01:06 -0700 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: Thu, 26 Mar 2009 09:01:05 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105BB53FC@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <49CB9397.5090909@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-jiang-incremental-cgn-00.txt Thread-Index: AcmuIKv3qt2bvwKETv6AYvMtVUWkHAACxSGQ References: <49CABA6C.4000906@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A105BB5267@XCH-NW-7V2.nw.nos.boeing.com> <49CB9397.5090909@gmail.com> From: "Templin, Fred L" To: "Brian E Carpenter" X-OriginalArrivalTime: 26 Mar 2009 16:01:06.0447 (UTC) FILETIME=[123BC1F0:01C9AE2C] Cc: Behave WG , draft-jiang-incremental-cgn@tools.ietf.org Subject: Re: [BEHAVE] Comments on draft-jiang-incremental-cgn-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, 26 Mar 2009 16:00:19 -0000 Brian, > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Thursday, March 26, 2009 7:39 AM > To: Templin, Fred L > Cc: Behave WG; draft-jiang-incremental-cgn@tools.ietf.org > Subject: Re: Comments on draft-jiang-incremental-cgn-00.txt >=20 > Fred, >=20 > Thanks for your comment. I think placement of NAT64 functions > will be an interesting discussion - essentially you seem to be > suggesting that in the 'IPv4 network connects to IPv6 Internet' > scenario, the IPv4 network is limited to whatever is behind > an individual CPE. That does appear to have a scaling advantage, > but on the other hand it's a lot of extra logic to be shoved > inside a $99 CPE. I'm not a CPE vendor, but it seems simpler and more robust to have everything self-contained in the same box - fewer moving parts, and fewer things to go wrong. Thanks - Fred fred.l.templin@boeing.com > Brian >=20 > On 2009-03-26 18:57, Templin, Fred L wrote: > > This document appears to be in very good shape for a > > -00 draft, and I have only one observation for now. In > > Section 3, the sentence: "...NAT-PT [RFC2766, RFC4966] > > (or its replacement) can be integrated with CGN." - I > > am wondering here whether a NAT-PT or equivalent > > function could also reside within the Dual-Stack > > Home Gateway (HG) such that the state maintenance, > > DNS, fate sharing, etc. is kept close to the hosts? > > > > Then, let the CGN become a dual-stack IPv6 router, and > > the ISP network can be traversed via an IPv6/IPv4 tunnel. > > Consider also that tunnels could go from HG(A) to HG(B) > > within the same ISP network. Only the HGs and CGNs > > are touched while the ISP network can remain as IPv4, > > so the scenario begins to look very much like VET. > > > > In this sort of arrangement, for an IPv4-only host in > > the home network connecting to an IPv4 server in the > > Internet, the HG just lets it go as IPv4 using NAT44. > > For an IPv4-only host connecting to an IPv6 server, > > however, the HG's NAT-PT function (or equivalent) would > > establish the necessary state such that IPv4 packets > > going out are translated to IPv6, and IPv6 packets > > coming in are translated to IPv4. > > > > For an IPv6-only host in the home network connecting > > to an IPv6 server, the HG just lets it go as IPv6, > > tunneled over IPv4 in the ISP network if necessary. > > For an IPv6-only host connecting to an IPv4 server, > > however, discover the server's address ('a.b.c.d') > > and map it to a special-use IPv6 /96 prefix, e.g., as > > "f00::a.b.c.d/96". Let the CGN advertise reachability > > to "f00::/96" such that the HG's IPv6 packets are > > conveyed to the CGN. The CGN then translates the > > IPv6 packets going out into IPv4 packets, and uses > > NAT44 to forward them on to the IPv4 server (with > > IPv4-to-IPv6 translation in the reverse path). In > > this sense, "f00::/96" represents the entire IPv4 > > Internet. > > > > So, there are two seperate and complimentary NAT-PT > > (or equivalent) functions - one in the HG and one in > > the CGN - but each presents a slightly different > > service model as described above. Is this something > > like what you had in mind? > > > > Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: Wednesday, March 25, 2009 4:13 PM > >> To: Behave WG > >> Cc: draft-jiang-incremental-cgn@tools.ietf.org > >> Subject: [BEHAVE] draft-jiang-incremental-cgn-00.txt > >> > >> This draft was discussed in v6ops, but the authors would be interested > >> in comments from BEHAVE as well. We'll start working on the next > > version > >> in a couple of weeks, so please comment soon. > >> > >> The slides are at > >> http://www3.ietf.org/proceedings/09mar/slides/v6ops-7.pdf > >> > >> Brian > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > > From charliep@wichorus.com Thu Mar 26 11: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 0BFE73A6A8E for ; Thu, 26 Mar 2009 11:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvANohuXyLtN for ; Thu, 26 Mar 2009 11:04:38 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 159E33A6838 for ; Thu, 26 Mar 2009 11:04:38 -0700 (PDT) Received: from [130.129.83.215] by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LmtxJ-0007Yr-Ui; Thu, 26 Mar 2009 14:05:30 -0400 Message-ID: <49CBC3E9.2000308@wichorus.com> Date: Thu, 26 Mar 2009 11:05:29 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pierre.levis@orange-ftgroup.com References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52389c9d3f90f54cb7eb2a1559f078b564350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.83.215 Cc: marc.blanchet@viagenie.ca, behave@ietf.org Subject: Re: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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, 26 Mar 2009 18:04:39 -0000 Hello Pierre, There is the possibility to do this. However, the payoff is so small, that I wonder if anyone would bother. Nevertheless, the impact should be assessed. As it was presented yesterday, the attack is a threat. In order to have long-term effects, it would have to be done repeatedly. That might increase the opportunity for detection. It might also be possible to blacklist incoming packets from address ranges that are misbehaving. Yesterday, Mark Andrews pointed out that there is a very good reason to leave the port "accessible" to packets with new source IP addresses. This also has the effect of mitigating the particular DOS attack mentioned in your message. I will be taking a detailed look at this. Regards, Charlie P. pierre.levis@orange-ftgroup.com wrote: > If I've understood well, there is also a possibility to directly attack the IPv4 address pool. > Assuming an attacker knows this pool, he can generate packets (with different source addresses) towards this pool, and hence eat most of the pending mappings before the real packets arrive. It will be diffcult to filter because the NAT does not know what source addresses are legitimate. > > Pierre > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Marc Blanchet > Envoyé : mercredi 25 mars 2009 19:47 > Ŕ : Charles E. Perkins > Cc : behave@ietf.org > Objet : [BEHAVE] DOS regarding draft-perkins-sourceipnat-00 > > the question I had on the mike today: > - given that the TTL of the name need to be low > - what happens if I write a 2 line loop script which queries the name as > fast and as many as I can? it would then create new mappings on the > translator for each request. Therefore, end up pretty fast to allocate > all ressources on the NAT. therefore, no more available until the > timeouts start to happen, which can't be too short... > > How to mitigate that problem? > > Marc. > From remi.despres@free.fr Thu Mar 26 13:32: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 C26793A6987 for ; Thu, 26 Mar 2009 13:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.616 X-Spam-Level: * X-Spam-Status: No, score=1.616 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 UVTuY4MUzbC9 for ; Thu, 26 Mar 2009 13:32:00 -0700 (PDT) Received: from smtp21.orange.fr (unknown [80.12.242.46]) by core3.amsl.com (Postfix) with ESMTP id 087CB3A6867 for ; Thu, 26 Mar 2009 13:32:00 -0700 (PDT) Received: from dhcp-17b6.meeting.ietf.org (dhcp-17b6.meeting.ietf.org [130.129.23.182]) by mwinf2104.orange.fr (SMTP Server) with ESMTP id 95D552000088; Thu, 26 Mar 2009 21:32:52 +0100 (CET) X-ME-UUID: 20090326203252613.95D552000088@mwinf2104.orange.fr Message-ID: <49CBE5F8.1000106@free.fr> Date: Thu, 26 Mar 2009 13:30:48 -0700 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Marc Blanchet References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> In-Reply-To: <49CA7C1D.9030700@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: "Charles E. Perkins" , behave@ietf.org Subject: Re: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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, 26 Mar 2009 20:32:00 -0000 Marc Blanchet - le (m/j/a) 3/25/09 11:46 AM: > the question I had on the mike today: > - given that the TTL of the name need to be low > - what happens if I write a 2 line loop script which queries the name as > fast and as many as I can? it would then create new mappings on the > translator for each request. Therefore, end up pretty fast to allocate > all ressources on the NAT. therefore, no more available until the > timeouts start to happen, which can't be too short... > > How to mitigate that problem? > To _mitigate_ it (not to solve it completely), it would be easy to limit the number of current mappings _per URL_. (Thus DOS attacks on one URL, or on a number of them, would not impact others.) Regards, RD From marc.blanchet@viagenie.ca Thu Mar 26 13:40: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 646EF3A6827 for ; Thu, 26 Mar 2009 13:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, 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 NBQFxbJYPawG for ; Thu, 26 Mar 2009 13:40:45 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 58DE23A6903 for ; Thu, 26 Mar 2009 13:40:45 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id E31C229E157D; Thu, 26 Mar 2009 16:41:38 -0400 (EDT) Received: from dhcp-53fe.meeting.ietf.org (unknown [130.129.83.254]) by jazz.viagenie.ca (Postfix) with ESMTP id 6155429E156D; Thu, 26 Mar 2009 16:41:38 -0400 (EDT) Message-ID: <49CBE881.3070102@viagenie.ca> Date: Thu, 26 Mar 2009 13:41:37 -0700 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> <49CBE5F8.1000106@free.fr> In-Reply-To: <49CBE5F8.1000106@free.fr> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "Charles E. Perkins" , behave@ietf.org Subject: Re: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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, 26 Mar 2009 20:40:46 -0000 Rémi Després a écrit : > Marc Blanchet - le (m/j/a) 3/25/09 11:46 AM: >> the question I had on the mike today: >> - given that the TTL of the name need to be low >> - what happens if I write a 2 line loop script which queries the name as >> fast and as many as I can? it would then create new mappings on the >> translator for each request. Therefore, end up pretty fast to allocate >> all ressources on the NAT. therefore, no more available until the >> timeouts start to happen, which can't be too short... >> >> How to mitigate that problem? >> > To _mitigate_ it (not to solve it completely), it would be easy to limit > the number of current mappings _per URL_. > (Thus DOS attacks on one URL, or on a number of them, would not impact > others.) don't understand it. here is my understanding: - user request a name - dns resolution path goes to the sourceip-nat DNS server - DNS server returns IP address and opens the NAT mapping in this list, I don't see where URL are. does not seem relevant to me. I guess I'm missing something. Marc. > > Regards, > > RD > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From simon.perreault@viagenie.ca Thu Mar 26 13:46: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 E43DE3A68AC for ; Thu, 26 Mar 2009 13:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 juoDdpIW1qdI for ; Thu, 26 Mar 2009 13:46:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 1C18C3A67F2 for ; Thu, 26 Mar 2009 13:46:39 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id A6E4629E157D; Thu, 26 Mar 2009 16:47:32 -0400 (EDT) Received: from dhcp-13e3.meeting.ietf.org (unknown [IPv6:2001:df8:0:16:20a:95ff:fef7:a2af]) by jazz.viagenie.ca (Postfix) with ESMTP id B7EFC29E156D; Thu, 26 Mar 2009 16:47:31 -0400 (EDT) Message-ID: <49CBE9E2.2000704@viagenie.ca> Date: Thu, 26 Mar 2009 13:47:30 -0700 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> <49CBE5F8.1000106@free.fr> In-Reply-To: <49CBE5F8.1000106@free.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "Charles E. Perkins" , Marc Blanchet , behave@ietf.org Subject: Re: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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, 26 Mar 2009 20:46:40 -0000 Rémi Després wrote: > To _mitigate_ it (not to solve it completely), it would be easy to limit > the number of current mappings _per URL_. > (Thus DOS attacks on one URL, or on a number of them, would not impact > others.) I'm not sure I understand this. Suppose you have N names and M addresses in the pool. If M >= N, then you have no need for this draft. If M < N and you impose the lowest possible limit (i.e. 1), you haven't solved anything. Just allocate all M addresses to names you don't care about while the others are being DOSed. Blocking the addresses of clients sending DNS requests with the evil bit set is out of question since you probably don't want to block resolving DNS servers that are sending requests on behalf of the attacker. I find this security issue so overwhelming that I doubt I understand the method correctly. Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From remi.despres@free.fr Thu Mar 26 14: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 5F9093A6955 for ; Thu, 26 Mar 2009 14:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.033 X-Spam-Level: ** X-Spam-Status: No, score=2.033 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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 YORgXciSFN6W for ; Thu, 26 Mar 2009 14:39:05 -0700 (PDT) Received: from smtp21.orange.fr (unknown [80.12.242.46]) by core3.amsl.com (Postfix) with ESMTP id 6A48D3A676A for ; Thu, 26 Mar 2009 14:39:05 -0700 (PDT) Received: from dhcp-17b6.meeting.ietf.org (dhcp-17b6.meeting.ietf.org [130.129.23.182]) by mwinf2106.orange.fr (SMTP Server) with ESMTP id E50521C00096; Thu, 26 Mar 2009 22:39:57 +0100 (CET) X-ME-UUID: 20090326213957939.E50521C00096@mwinf2106.orange.fr Message-ID: <49CBF5AF.1030506@free.fr> Date: Thu, 26 Mar 2009 14:37:51 -0700 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Marc Blanchet References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> <49CBE5F8.1000106@free.fr> <49CBE881.3070102@viagenie.ca> In-Reply-To: <49CBE881.3070102@viagenie.ca> Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Cc: "Charles E. Perkins" , behave@ietf.org Subject: Re: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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, 26 Mar 2009 21:39:06 -0000 Marc Blanchet  -  le (m/j/a) 3/26/09 1:41 PM: 
Rémi Després a écrit :
  
Marc Blanchet  -  le (m/j/a) 3/25/09 11:46 AM:
    
the question I had on the mike today:
- given that the TTL of the name need to be low
- what happens if I write a 2 line loop script which queries the name as
fast and as many as I can? it would then create new mappings on the
translator for each request. Therefore, end up pretty fast to allocate
all ressources on the NAT. therefore, no more available until the
timeouts start to happen, which can't be too short...

How to mitigate that problem?
  
      
To _mitigate_ it (not to solve it completely), it would be easy to limit
the number of current mappings _per URL_.
(Thus DOS attacks on one URL, or on a number of them, would not impact
others.)
    

don't understand it. here is my understanding:
- user request a name
- dns resolution path goes to the sourceip-nat DNS server
- DNS server returns IP address and opens the NAT mapping

in this list, I don't see where URL are. does not seem relevant to me. I
guess I'm missing something.
I guess I should have said "name" instead of URL.

This being done, assume a DNS that manages temporary mappings as Charlie proposes has a bound on the number of mappings it accepts for each name. Then the attack on name aa will not be sufficient to take all resources of the NAT. The attacker will have to attack many names mapped to the same NAT (names ab, ac, etc... which must be real names in the DNS to do some harm).

RD

From simon.perreault@viagenie.ca Thu Mar 26 14:49: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 6D4CC3A6887 for ; Thu, 26 Mar 2009 14:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 x4EYZgKSoDSa for ; Thu, 26 Mar 2009 14:49:30 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 7AD4A28C10A for ; Thu, 26 Mar 2009 14:49:30 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 2535929E157E; Thu, 26 Mar 2009 17:50:24 -0400 (EDT) Received: from dhcp-13e3.meeting.ietf.org (unknown [IPv6:2001:df8:0:16:20a:95ff:fef7:a2af]) by jazz.viagenie.ca (Postfix) with ESMTP id A4B9429E156D; Thu, 26 Mar 2009 17:50:23 -0400 (EDT) Message-ID: <49CBF89E.2070301@viagenie.ca> Date: Thu, 26 Mar 2009 14:50:22 -0700 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> <49CBE5F8.1000106@free.fr> <49CBE9E2.2000704@viagenie.ca> <49CBF74D.6090908@free.fr> In-Reply-To: <49CBF74D.6090908@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Cc: Behave WG Subject: Re: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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, 26 Mar 2009 21:49:31 -0000 Rémi Després wrote: > This idea is not to block those who send too many requests, but only to > avoid that an attack on a given name would be sufficient to consume all > mapping resources of the DNS and the NAT. I do not understand this. Suppose you have a.com, b.com, and c.com, along with two IP addresses. An attacker keeps a.com and b.com mapped to IP addresses by sending DNS requests for these domains. c.com is DOSed. Concretely, how can this attack be mitigated? Thanks, Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From charliep@wichorus.com Thu Mar 26 15:14: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 37B4128C16E for ; Thu, 26 Mar 2009 15:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTA8cCHetckZ for ; Thu, 26 Mar 2009 15:14:31 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 78F8B28C160 for ; Thu, 26 Mar 2009 15:14:31 -0700 (PDT) Received: from [130.129.83.215] by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lmxr9-0004EN-W6; Thu, 26 Mar 2009 18:15:24 -0400 Message-ID: <49CBFE7B.8080504@wichorus.com> Date: Thu, 26 Mar 2009 15:15:23 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Simon Perreault References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> <49CBE5F8.1000106@free.fr> <49CBE9E2.2000704@viagenie.ca> <49CBF74D.6090908@free.fr> <49CBF89E.2070301@viagenie.ca> In-Reply-To: <49CBF89E.2070301@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5218334d8a65e7a407767eedbde5dbc1a8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.83.215 Cc: Behave WG Subject: Re: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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, 26 Mar 2009 22:14:32 -0000 Hello Simon, Do you mean that the attacker continuously sends DNS requests for a.com and b.com? If so, doesn't this increase the opportunity for detection? Regards, Charlie P. Simon Perreault wrote: > Rémi Després wrote: > >> This idea is not to block those who send too many requests, but only to >> avoid that an attack on a given name would be sufficient to consume all >> mapping resources of the DNS and the NAT. >> > > I do not understand this. > > Suppose you have a.com, b.com, and c.com, along with two IP addresses. > > An attacker keeps a.com and b.com mapped to IP addresses by sending DNS > requests for these domains. > > c.com is DOSed. > > Concretely, how can this attack be mitigated? > > Thanks, > Simon > From marc.blanchet@viagenie.ca Thu Mar 26 15:38: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 537D53A67F2 for ; Thu, 26 Mar 2009 15:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.383 X-Spam-Level: X-Spam-Status: No, score=-0.383 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 E59pz7RaZrLO for ; Thu, 26 Mar 2009 15:38:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 5EBE028C104 for ; Thu, 26 Mar 2009 15:38:14 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 11C4E29E157D; Thu, 26 Mar 2009 18:39:08 -0400 (EDT) Received: from dhcp-53fe.meeting.ietf.org (unknown [130.129.83.254]) by jazz.viagenie.ca (Postfix) with ESMTP id 7ACF929E156D; Thu, 26 Mar 2009 18:39:07 -0400 (EDT) Message-ID: <49CC040A.1060402@viagenie.ca> Date: Thu, 26 Mar 2009 15:39:06 -0700 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Charles E. Perkins" References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> <49CBE5F8.1000106@free.fr> <49CBE9E2.2000704@viagenie.ca> <49CBF74D.6090908@free.fr> <49CBF89E.2070301@viagenie.ca> <49CBFE7B.8080504@wichorus.com> In-Reply-To: <49CBFE7B.8080504@wichorus.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Cc: Behave WG Subject: Re: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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, 26 Mar 2009 22:38:16 -0000 Charles E. Perkins a écrit : > > Hello Simon, > > Do you mean that the attacker continuously sends > DNS requests for a.com and b.com? > > If so, doesn't this increase the opportunity for > detection? not really, because the key is that the attacker source address is not seen by the sourceip-nat DNS server. The DNS request packet received by sourceip-nat DNS server is from some other DNS servers. These might be broadband provider DNS server that you would not block. therefore, it looks difficult to detect and to filter. Marc. > > Regards, > Charlie P. > > > Simon Perreault wrote: >> Rémi Després wrote: >> >>> This idea is not to block those who send too many requests, but only to >>> avoid that an attack on a given name would be sufficient to consume all >>> mapping resources of the DNS and the NAT. >>> >> >> I do not understand this. >> >> Suppose you have a.com, b.com, and c.com, along with two IP addresses. >> >> An attacker keeps a.com and b.com mapped to IP addresses by sending DNS >> requests for these domains. >> >> c.com is DOSed. >> >> Concretely, how can this attack be mitigated? >> >> Thanks, >> Simon >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From simon.perreault@viagenie.ca Thu Mar 26 17:40: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 8D7633A6A8E for ; Thu, 26 Mar 2009 17:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.120, 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 YpXajtot95zN for ; Thu, 26 Mar 2009 17:40:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 6FB303A6862 for ; Thu, 26 Mar 2009 17:40:33 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 374B129E157E; Thu, 26 Mar 2009 20:41:27 -0400 (EDT) Received: from dhcp-13e3.meeting.ietf.org (unknown [IPv6:2001:df8:0:16:20a:95ff:fef7:a2af]) by jazz.viagenie.ca (Postfix) with ESMTP id B4BF329E156D; Thu, 26 Mar 2009 20:41:25 -0400 (EDT) Message-ID: <49CC20B3.6050106@viagenie.ca> Date: Thu, 26 Mar 2009 17:41:23 -0700 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Charles E. Perkins" References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> <49CBE5F8.1000106@free.fr> <49CBE9E2.2000704@viagenie.ca> <49CBF74D.6090908@free.fr> <49CBF89E.2070301@viagenie.ca> <49CBFE7B.8080504@wichorus.com> In-Reply-To: <49CBFE7B.8080504@wichorus.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Behave WG Subject: Re: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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: Fri, 27 Mar 2009 00:40:34 -0000 Charles E. Perkins wrote: > Do you mean that the attacker continuously sends > DNS requests for a.com and b.com? Yes, every 1-2 seconds (according to the TTL). > If so, doesn't this increase the opportunity for > detection? The authoritative DNS server will detect evil requests, yes. The solution would be to ban the requester. However, it is very possible that the requests will come from a legitimate recursive DNS server being abused by the real attacker. You cannot block requests coming from this server because legitimate users may be trying to reach you using this same recursive DNS server. I have more and more the feeling that I got something wrong. I am looking forward to enlightenment. Thanks, Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From charliep@wichorus.com Thu Mar 26 18:10: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 EA3793A685A for ; Thu, 26 Mar 2009 18:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E201S0Db529s for ; Thu, 26 Mar 2009 18:10:03 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 036E03A6B24 for ; Thu, 26 Mar 2009 18:10:03 -0700 (PDT) Received: from [130.129.83.215] by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ln0b1-0001zA-Ul; Thu, 26 Mar 2009 21:10:56 -0400 Message-ID: <49CC279F.703@wichorus.com> Date: Thu, 26 Mar 2009 18:10:55 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Simon Perreault References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> <49CBE5F8.1000106@free.fr> <49CBE9E2.2000704@viagenie.ca> <49CBF74D.6090908@free.fr> <49CBF89E.2070301@viagenie.ca> <49CBFE7B.8080504@wichorus.com> <49CC20B3.6050106@viagenie.ca> In-Reply-To: <49CC20B3.6050106@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5262246e04e7a366d7b94cce26825a1d9b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.83.215 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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: Fri, 27 Mar 2009 01:10:05 -0000 Hello Simon, Simon Perreault wrote: > > The authoritative DNS server will detect evil requests, yes. The > solution would be to ban the requester. However, it is very possible > that the requests will come from a legitimate recursive DNS server being > abused by the real attacker. You cannot block requests coming from this > server because legitimate users may be trying to reach you using this > same recursive DNS server. > Right. But we could do something to enforce fairness, by making sure that requests are served in order. I mentioned buffering the DNS Requests. I think there are other implementation techniques also that could be useful. > I have more and more the feeling that I got something wrong. I am > looking forward to enlightenment. > No, I don't think you have got it wrong. How do you think this compares against existing DOS mechanisms? The mechanisms for mitigating attacks on sourceIP_NAT remain to be investigated for the most part, but it seems at least doable to make the attacks "less interesting" to the attackers than other easier attacks. Regards, Charlie P. From simon.perreault@viagenie.ca Thu Mar 26 18:32: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 442DA3A6A37 for ; Thu, 26 Mar 2009 18:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.111, 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 6cOSI9gJ9o7N for ; Thu, 26 Mar 2009 18:32:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 206F83A6807 for ; Thu, 26 Mar 2009 18:32:40 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id E418D29E157E; Thu, 26 Mar 2009 21:33:33 -0400 (EDT) Received: from dhcp-13e3.meeting.ietf.org (unknown [IPv6:2001:df8:0:16:20a:95ff:fef7:a2af]) by jazz.viagenie.ca (Postfix) with ESMTP id C57E729E156D; Thu, 26 Mar 2009 21:33:32 -0400 (EDT) Message-ID: <49CC2CEB.3080600@viagenie.ca> Date: Thu, 26 Mar 2009 18:33:31 -0700 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Charles E. Perkins" References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> <49CBE5F8.1000106@free.fr> <49CBE9E2.2000704@viagenie.ca> <49CBF74D.6090908@free.fr> <49CBF89E.2070301@viagenie.ca> <49CBFE7B.8080504@wichorus.com> <49CC20B3.6050106@viagenie.ca> <49CC279F.703@wichorus.com> In-Reply-To: <49CC279F.703@wichorus.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] DOS regarding draft-perkins-sourceipnat-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: Fri, 27 Mar 2009 01:32:41 -0000 Charles E. Perkins wrote: > How do you think this compares against existing DOS mechanisms? - A preliminary step is to discover a set of names mapped to the same address pool as the name that is the target of the attack. A number of name at least equal to the number of addresses in the pool is needed. Publication of NSEC RRs by the subject of the attack may make this step trivial. - Performing the attack only requires from the attacker to be able to send a number of DNS requests per second equal to the number of names identified in the preliminary step (assuming a TTL equal to one second). This represents a very low necessary upstream bandwidth. - The identity of the attacker is not revealed when it is using a legitimate recursive DNS server. Any broadband ISP provides such a server. Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From moore@network-heretics.com Thu Mar 26 19:08: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 4883628C154 for ; Thu, 26 Mar 2009 19:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXHtOOYHTgTE for ; Thu, 26 Mar 2009 19:08:13 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id EDE263A6BE5 for ; Thu, 26 Mar 2009 19:07:46 -0700 (PDT) Received: from lust.indecency.org (173-117-10-8.pools.spcsdns.net [173.117.10.8]) by m1.imap-partners.net (MOS 3.10.3-GA) with ESMTP id BLF02686 (AUTH admin@network-heretics.com) for behave@ietf.org; Thu, 26 Mar 2009 19:08:35 -0700 (PDT) Message-ID: <49CC351B.50200@network-heretics.com> Date: Thu, 26 Mar 2009 19:08:27 -0700 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Charles E. Perkins" References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> <49CBE5F8.1000106@free.fr> <49CBE9E2.2000704@viagenie.ca> <49CBF74D.6090908@free.fr> <49CBF89E.2070301@viagenie.ca> <49CBFE7B.8080504@wichorus.com> <49CC20B3.6050106@viagenie.ca> <49CC279F.703@wichorus.com> <49CC2CEB.3080600@viagenie.ca> In-Reply-To: <49CC2CEB.3080600@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: [BEHAVE] comments on draft-perkins-sourceipnat-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: Fri, 27 Mar 2009 02:08:14 -0000 At this point I'm having a hard time believing that this proposal has much applicability. - it only works for protocols/implementations where a DNS query is made fairly soon (separately from each peer making use of the address of the host behind the NAT) before a connection is established - there appear to be constraints on applicability based on: - how much each of the services behind it is used, - how many IPv4 addresses are available to be NATted to the servers' addresses, - how many services are behind the DNS server/NAT - it's vulnerable to DoS attacks and it's easy to mount those attacks. So what is the space for which this proposal is a good solution, something that we could recommend? Can we describe it with any lucidity? Keith From Remi.Denis-Courmont@nokia.com Thu Mar 26 19:22: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 E2D0F3A697F for ; Thu, 26 Mar 2009 19:22:47 -0700 (PDT) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 3Hvb9VKPXZ3s for ; Thu, 26 Mar 2009 19:22:47 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 83BA73A6807 for ; Thu, 26 Mar 2009 19:22:43 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2R2NBKV025737 for ; Fri, 27 Mar 2009 04:23:33 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 04:23:16 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 04:23:12 +0200 Received: from leon.remlab.net (essapo-nirac25351.europe.nokia.com [10.162.253.51]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n2R2NAam019866 for ; Fri, 27 Mar 2009 04:23:10 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: "behave@ietf.org" Date: Fri, 27 Mar 2009 04:23:08 +0200 User-Agent: KMail/1.11.0 (Linux/2.6.28.9; KDE/4.2.0; i686; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903270423.08690.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 27 Mar 2009 02:23:12.0226 (UTC) FILETIME=[FA21A420:01C9AE82] X-Nokia-AV: Clean Subject: [BEHAVE] Nitpicking regarding draft-perkins-sourceipnat-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: Fri, 27 Mar 2009 02:22:48 -0000 Hello, I'd just like to point out that HTTP is a very very bad example of use for= =20 sourceipnat. The HTTP Host header has solved the same problem years ago and= is=20 at the heart of all mutualized (dirt cheap or free) HTTP hosting services. = =46or=20 dedicated HTTP servers, a reverse proxy can solve the problem all the same,= =20 without DNS or IP-layer hacks. SMTP and SIP are similarly non-issues. Then HTTP/TLS has a problem with legacy HTTP clients that don't so Server N= ame=20 Indication. There are many IETF protocols that would be better examples: FTP, POP, IMAP= =20 comes to mind. =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From moore@network-heretics.com Thu Mar 26 19:29: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 2DCE83A6807 for ; Thu, 26 Mar 2009 19:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 SumAEJJEbcBa for ; Thu, 26 Mar 2009 19:29:56 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 84B863A67D9 for ; Thu, 26 Mar 2009 19:29:56 -0700 (PDT) Received: from lust.indecency.org (173-117-10-8.pools.spcsdns.net [173.117.10.8]) by m1.imap-partners.net (MOS 3.10.3-GA) with ESMTP id BLF05109 (AUTH admin@network-heretics.com) for behave@ietf.org; Thu, 26 Mar 2009 19:30:47 -0700 (PDT) Message-ID: <49CC3A53.6050009@network-heretics.com> Date: Thu, 26 Mar 2009 19:30:43 -0700 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <200903270423.08690.remi.denis-courmont@nokia.com> In-Reply-To: <200903270423.08690.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Nitpicking regarding draft-perkins-sourceipnat-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: Fri, 27 Mar 2009 02:29:57 -0000 Rémi Denis-Courmont wrote: > Hello, > > I'd just like to point out that HTTP is a very very bad example of use for > sourceipnat. agreed. > There are many IETF protocols that would be better examples: FTP, POP, IMAP > comes to mind. for that matter, there are common conventions for each of FTP, POP and IMAP to allow a single server to be shared among multiple domains or even proxied to multiple backing servers. generally what is done is to append @hostname to the username when authenticating. Keith From charliep@wichorus.com Thu Mar 26 19:48: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 D61953A6A7F for ; Thu, 26 Mar 2009 19:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwxKMrcz6Oyl for ; Thu, 26 Mar 2009 19:48:49 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id CE5AF3A6A2C for ; Thu, 26 Mar 2009 19:48:48 -0700 (PDT) Received: from [130.129.83.215] by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ln28c-0004Wm-Gw; Thu, 26 Mar 2009 22:49:42 -0400 Message-ID: <49CC3EC4.7060503@wichorus.com> Date: Thu, 26 Mar 2009 19:49:40 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Keith Moore References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> <49CBE5F8.1000106@free.fr> <49CBE9E2.2000704@viagenie.ca> <49CBF74D.6090908@free.fr> <49CBF89E.2070301@viagenie.ca> <49CBFE7B.8080504@wichorus.com> <49CC20B3.6050106@viagenie.ca> <49CC279F.703@wichorus.com> <49CC2CEB.3080600@viagenie.ca> <49CC351B.50200@network-heretics.com> In-Reply-To: <49CC351B.50200@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5277067eecb2437c28c5b6848afeade921350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.83.215 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] comments on draft-perkins-sourceipnat-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: Fri, 27 Mar 2009 02:48:49 -0000 Hello Keith, I think that the applicability is as I described it in my presentation. I expect that if a network operator serves a population of some thousands or more of small-to-medium businesses and websites, then the proposal should be applicable. It "works" on the datasets I have, given the right parameter choices. Keith Moore wrote: > At this point I'm having a hard time believing that this proposal has > much applicability. > > - it only works for protocols/implementations where a DNS query is made > fairly soon (separately from each peer making use of the address of the > host behind the NAT) before a connection is established > Right. I thought this was most of them, except for peer-to-peer. For these purposes, of course we could enable some explicit signaling for static or dynamic assignment of the IPv4 address to the IPv6-only peer. My proposal is never going to be the only tool for transition. > - there appear to be constraints on applicability based on: > - how much each of the services behind it is used, > - how many IPv4 addresses are available to be NATted to the servers' > addresses, > - how many services are behind the DNS server/NAT > You are right. These are the considerations/constraints. > - it's vulnerable to DoS attacks and it's easy to mount those attacks. > Perhaps there could be some help for these problems. > So what is the space for which this proposal is a good solution, > something that we could recommend? Can we describe it with any lucidity? > I hope my comments above are lucid. I gather you would not want to see statistics for applicability based on the number of DNS requests per second. I really want to know if you disagree with my observation that, unless businesses can serve their customers from a v6-based platform, they will strongly oppose any suggestion to move to IPv6. They will heat up the demand for IPv4 addresses and delay transition. Some might prefer a balkanized Internet instead of doing the "right thing". None of this is black and white. I understand my proposal is not perfect; in fact, it is imperfect in several ways. However, compared to what we have now to encourage adoption of IPv6, it seems very useful. And, I really have to emphasize that somehow NAT managed to proliferate because it served certain needs -- I'm not claiming NAT is great, either! In fact just the opposite. Another point about the number of NATv4 addresses... First, temporarily grant my hypothesis that this could be a useful tool for transition, and grant my observation that the system works best with at least a few hundred IPv4 addresses for the NAT. Then it might be important to reserve some of the existing IPv4 address space for the purpose of enabling this way of accelerating IPv6 transition (or, at least, eliminating an important inhibition against IPv6 transition). I'll submit another draft in a few weeks taking recent suggestions into account. Regards, Charlie P. From moore@network-heretics.com Fri Mar 27 01:32: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 9676A3A698B for ; Fri, 27 Mar 2009 01:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I27PrZnIaYjz for ; Fri, 27 Mar 2009 01:32:12 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id CF0D93A68EB for ; Fri, 27 Mar 2009 01:32:12 -0700 (PDT) Received: from lust.indecency.org (dhcp-41c5.meeting.ietf.org [130.129.65.197]) by m1.imap-partners.net (MOS 3.10.3-GA) with ESMTP id BLF42780 (AUTH admin@network-heretics.com) for behave@ietf.org; Fri, 27 Mar 2009 01:33:06 -0700 (PDT) Message-ID: <49CC8F3E.3060008@network-heretics.com> Date: Fri, 27 Mar 2009 01:33:02 -0700 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Charles E. Perkins" References: <499F1ED9.9010006@wichorus.com> <49CA7AFC.9000803@ericsson.com> <49CA7C1D.9030700@viagenie.ca> <49CBE5F8.1000106@free.fr> <49CBE9E2.2000704@viagenie.ca> <49CBF74D.6090908@free.fr> <49CBF89E.2070301@viagenie.ca> <49CBFE7B.8080504@wichorus.com> <49CC20B3.6050106@viagenie.ca> <49CC279F.703@wichorus.com> <49CC2CEB.3080600@viagenie.ca> <49CC351B.50200@network-heretics.com> <49CC3EC4.7060503@wichorus.com> In-Reply-To: <49CC3EC4.7060503@wichorus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] comments on draft-perkins-sourceipnat-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: Fri, 27 Mar 2009 08:32:13 -0000 Charles E. Perkins wrote: > I really want to know if you disagree with my observation that, unless > businesses can serve their customers from a v6-based platform, they > will strongly oppose any suggestion to move to IPv6. Heavens, no. I agree with that entirely. I just think we need to try to be clear about the applicability of all of our proposals, and I also think that the potential for DoS attacks (in particular) limits the applicability of this one. I also think that even if the DoS potential can be dealt with (and I don't see a way to do that offhand) that it's hard to describe the applicability of this proposal because it's something like a three-dimensional space with number of IPv4 addresses on the x axis, number of servers on the y axis, and frequency of access per server on the z axis. Perhaps you could model that given your test data, but could you describe the results in terms that a potential user could understand and which would still be accurate? > Another point about the number of NATv4 addresses... First, temporarily > grant my hypothesis that this could be a useful tool for transition, and > grant my observation that the system works best with at least a few hundred > IPv4 addresses for the NAT. Then it might be important to reserve some > of the existing IPv4 address space for the purpose of enabling this > way of accelerating IPv6 transition (or, at least, eliminating an important > inhibition against IPv6 transition). One thing I'll note is that this proposal doesn't have to be standardized to be used. That is, it doesn't require any changes to the appliciations that use this mechanism on either the client or server end. All it requires is a NAT and a DNS server that cooperate with one another, and someone who is willing to try to make a business out of selling IPv4 access using this mechanism. Keith From xing@cernet.edu.cn Fri Mar 27 07:06: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 9191D3A6AA1 for ; Fri, 27 Mar 2009 07:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 XJ7tz7XtmSVq for ; Fri, 27 Mar 2009 07:06:22 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id DC67A3A6929 for ; Fri, 27 Mar 2009 07:06:20 -0700 (PDT) Received: from [127.0.0.1]([123.112.83.83]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmc49cce761; Fri, 27 Mar 2009 22:07:12 +0800 Message-ID: <49CCDD7D.3000704@cernet.edu.cn> Date: Fri, 27 Mar 2009 22:06:53 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <67DFA2B0-AC2A-4E02-86B5-DDF30BB40CA1@tahi.org> <49CB85A9.6090903@cernet.edu.cn> <49CB9763.4060705@it.uc3m.es> In-Reply-To: <49CB9763.4060705@it.uc3m.es> 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: 7ZQiMnVB Cc: Behave WG , Hiroshi MIYATA , Fred Baker , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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, 27 Mar 2009 14:06:23 -0000 marcelo bagnulo braun 写é“: > Xing Li escribiĂł: >> Hiroshi MIYATA 写é“: >>> Fred, >>> >>> I agree making separate prefix recommendation document, since we >>> would have well known >>> prefix for translator. >>> WKP would work with some restriction, like IPv6 network to IPv4 >>> internet. >> >> For the stateless translator, the LIR is the only choice since we >> should not insert the global IPv4 routing table into global IPv6 >> routing system. >> > imho this problem is not related to stateless or statefull, but > related to whether the scenario involves an IPv6 network or the IPv6 > Internet (i.e. by definition, you cannot inject the IPv4 routing table > into the IPv6 internet if the scenarion does not involves the IPv6 > internet) > It is strongle related to the stateless/stateful mode. Please see text in the framework document. 2.2.1. LIR prefix versus Well-Known prefix 2.2.1.1. Stateless mode 2.2.1.1.1. IPv6 Routing system scalability In the stateless mode, the more specifics inside the IPv4-embedded IPv6 address block are used to represent the IPv6 end systems, therefore the LIR prefix should be used. The reason is that the LIR prefix can be aggregated in the ISP's border routers and will not affect the global IPv6 routing system. On the other hand, if the Well-Known prefix is used, the global IPv4 routing table will be inserted into the global IPv6 routing system, which is known to be a very bad idea. In the stateless mode, it is possible to use LIR prefix to represent the IPv6 addresses in the IPv4 Internet and use Well-Known prefix to represent the IPv4 addresses in the IPv6 Internet. However, this is also a bad idea. The reason is that there will be two possible IPv6 addresses to represent a single IPv4 host, i.e. if the IPv4 address is used by a host in the IPv4 Internet, a Well-Known prefix should be used; if the IPv4 address (as IVI6) is used by a host in the IPv6 Internet, a LIR prefix should be used. The IVI6 hosts must know which one to use in order to communicate with that host. However, if the LIR prefix is used in both representations, this problem is solved by the "more specific win" routing principle. The potential leakage of the IPv6 more specifics introduced by using LIR prefix could be controlled by ISP's general routing practice, since this specific is the same compared with other more specifics inside ISP's autonomous system. http://tools.ietf.org/html/draft-baker-behave-v4v6-framework-02 regards, xing > regards, marcelo > >>> >>> >>> Which document we should based on is another discussion. ;-) >>> >> In the draft-baker-behave-v4v6-framework-02.txt, it summarizes both >> the stateless and the stateful modes of the translator, while the >> others only address the stateful mode. >> >> xing >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > From brian.e.carpenter@gmail.com Fri Mar 27 07:46: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 C113D3A6C5D for ; Fri, 27 Mar 2009 07:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 pHuOH9kc3FS9 for ; Fri, 27 Mar 2009 07:46:30 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id C75683A6B8C for ; Fri, 27 Mar 2009 07:46:30 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1351070wfg.31 for ; Fri, 27 Mar 2009 07:47:25 -0700 (PDT) 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=dNNpaZTXqkxUiJ21I4wxiyunWco7XPDXbrheu2iqbl4=; b=TGeq5wb9qxgW2ld/6gvhRaV2SiWYL8hdfHqjDV+0ktuvZRDtf2/mClC2uI6WOzzNDE GqxZ8R3pjSMC6a6af2ZpM48PZtpHxydmVb/vk6tFojMVr/ocFtiTrgomaF/q2B+Y3i27 0rjcvrD8eTTrEmLejh6WQeC7CwMeTHN+YyR8w= 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=YX/wi0zkQ1EIjcJSsK2G6zRp8CzhCAG8S5SmyXT9J1EqvYXzZnHb6+rxS1ADDn3rNe TBgKiZkKUPCpeDr9tt5iArCXgblxkFUYFfygQZ/rnbNKVPrtcTWlRpirbwdr7vheGQ3F /OK1cD887+IbHG9HfdE6LaAXfvrJmu+OcrBFk= Received: by 10.142.162.9 with SMTP id k9mr929320wfe.164.1238165245552; Fri, 27 Mar 2009 07:47:25 -0700 (PDT) Received: from ?130.129.64.245? (dhcp-40f5.meeting.ietf.org [130.129.64.245]) by mx.google.com with ESMTPS id 31sm2966655wff.56.2009.03.27.07.47.23 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Mar 2009 07:47:25 -0700 (PDT) Message-ID: <49CCE6F4.5020903@gmail.com> Date: Sat, 28 Mar 2009 03:47:16 +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: <67DFA2B0-AC2A-4E02-86B5-DDF30BB40CA1@tahi.org> <49CB85A9.6090903@cernet.edu.cn> <49CB9763.4060705@it.uc3m.es> <49CCDD7D.3000704@cernet.edu.cn> In-Reply-To: <49CCDD7D.3000704@cernet.edu.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hiroshi MIYATA , Behave WG , Fred Baker , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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, 27 Mar 2009 14:46:31 -0000 On 2009-03-28 03:06, Xing Li wrote: > marcelo bagnulo braun =E5=86=99=E9=81=93: >> Xing Li escribi=C3=B3: >>> Hiroshi MIYATA =E5=86=99=E9=81=93: >>>> Fred, >>>> >>>> I agree making separate prefix recommendation document, since we >>>> would have well known >>>> prefix for translator. >>>> WKP would work with some restriction, like IPv6 network to IPv4 >>>> internet. >>> >>> For the stateless translator, the LIR is the only choice since we >>> should not insert the global IPv4 routing table into global IPv6 >>> routing system. >>> >> imho this problem is not related to stateless or statefull, but >> related to whether the scenario involves an IPv6 network or the IPv6 >> Internet (i.e. by definition, you cannot inject the IPv4 routing table= >> into the IPv6 internet if the scenarion does not involves the IPv6 >> internet) >> >=20 > It is strongle related to the stateless/stateful mode. Please see text > in the framework document. >=20 > 2.2.1. LIR prefix versus Well-Known prefix > 2.2.1.1. Stateless mode > 2.2.1.1.1. IPv6 Routing system scalability >=20 >=20 > In the stateless mode, the more specifics inside the IPv4-embedded > IPv6 address block are used to represent the IPv6 end systems, > therefore the LIR prefix should be used. The reason is that the LIR > prefix can be aggregated in the ISP's border routers and will not > affect the global IPv6 routing system. On the other hand, if the > Well-Known prefix is used, the global IPv4 routing table will be > inserted into the global IPv6 routing system, which is known to be a > very bad idea. Agreed that it would be a very bad idea. But I don't understand why it would happen. It doesn't happen with 2002::/8. Actually the analysis in RFC3056 states that this WKP can only be used safely if the IPv4 network is not fragmented, i.e. you MUST NOT use 6to4 after the IPv4 global routing breaks up (in 500 years from now?). There would need to be a similar rule for a NAT64 WKP, I think. >=20 > In the stateless mode, it is possible to use LIR prefix to represent > the IPv6 addresses in the IPv4 Internet and use Well-Known prefix to > represent the IPv4 addresses in the IPv6 Internet. However, this is > also a bad idea. The reason is that there will be two possible IPv6 > addresses to represent a single IPv4 host, i.e. if the IPv4 address > is used by a host in the IPv4 Internet, a Well-Known prefix should be= > used; if the IPv4 address (as IVI6) is used by a host in the IPv6 > Internet, a LIR prefix should be used. The IVI6 hosts must know > which one to use in order to communicate with that host. However, if= > the LIR prefix is used in both representations, this problem is > solved by the "more specific win" routing principle. >=20 > The potential leakage of the IPv6 more specifics introduced by using > LIR prefix could be controlled by ISP's general routing practice, > since this specific is the same compared with other more specifics > inside ISP's autonomous system. And the same practice would need to be used for the WKP: more specifics not allowed. BTW that might recreate some of the black hole issues we see for 6to4. So maybe a WKP is not such a good idea. Brian From fred@cisco.com Fri Mar 27 08:04: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 ABA433A6A71 for ; Fri, 27 Mar 2009 08:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9JvlZiq6u7F for ; Fri, 27 Mar 2009 08:04:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E5F013A6AC9 for ; Fri, 27 Mar 2009 08:04:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,432,1233532800"; d="scan'208";a="162687087" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 27 Mar 2009 15:05:51 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2RF5ppG021748; Fri, 27 Mar 2009 08:05:51 -0700 Received: from dhcp-41cd.meeting.ietf.org (sjc-vpn6-478.cisco.com [10.21.121.222]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2RF5pSU016451; Fri, 27 Mar 2009 15:05:51 GMT Message-Id: From: Fred Baker To: Xing Li , MARCELO BAGNULO BRAUN In-Reply-To: <49CCDD7D.3000704@cernet.edu.cn> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Mar 2009 08:05:51 -0700 References: <67DFA2B0-AC2A-4E02-86B5-DDF30BB40CA1@tahi.org> <49CB85A9.6090903@cernet.edu.cn> <49CB9763.4060705@it.uc3m.es> <49CCDD7D.3000704@cernet.edu.cn> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1602; t=1238166351; x=1239030351; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[BEHAVE]=20Plan=20for=20IPv4/IPv6=20tra nslation=20documents |Sender:=20; bh=yYKWAG06x1gDmZHGjYEGIWZGFn7MFkSM7LILfo1RnVE=; b=mYfSr3iDBHkZOLWht/V9+2ziJ6FhavXtI9qJYICyulHknlUDEwZtij7b+c LfgGc1m8IJR3kD1CLjuQw0jr6rbjjDmL4VJH0B3WLg72l9IXvAgOgysC4f0a M/bNluBDqonp2qWdfMwWEMdE+tymWijFT4oHwXjiBYTeRtTI9HLMc=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Behave WG , Hiroshi MIYATA , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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, 27 Mar 2009 15:04:57 -0000 I think you guys are speaking at cross purposes. Let me try to disambiguate. Xing Li, your point is that the IPv4-in-IPv6 more specifics in the IVI network you run represent individual customers, and are aggregated into the common prefix on the IPv4 side of the translator, and that the entire IPv4 space is aggregated into what amounts to a default route on the IPv6 side. Your comment that IPv4 more-specifics should generally not be brought into the IPv6 network. Right? Marcelo, Your point about injecting the IPv4 Internet routing into "an IPv6 network" vs "the IPv6 Internet" is about the connectivity of that IPv6 network - we're only talking about the IPv6 Internet if the network in question is distributing routes throughout that network. Guys, please. As far as peering, CERNET2 peers with networks in the US,. Europe, and Japan. CERNET2 is part of the emerging IPv6 Internet. There is no call to say otherwise. As to the issue of injection of routes, if CERNET2 was using a magic prefix, it would not advertise that (or the IPv4 routes it would imply) to its IPv6 neighbors, and one hopes that if it erroneously did so its neighbors would refuse the route. So in that case it would not provide IPv4 connectivity to its peers. However, if it is simply advertising its own prefix to its peers, it in effect is offering transit service to its IPv4-mapped prefix (which is part of its LIR prefix). I would imagine that CERNET2 advertises a set of less- specifics that in fact don't offer transit to the IPv4 network. From Fred.L.Templin@boeing.com Fri Mar 27 10:11: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 299983A6C5E for ; Fri, 27 Mar 2009 10:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.591 X-Spam-Level: X-Spam-Status: No, score=-4.591 tagged_above=-999 required=5 tests=[AWL=-1.381, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=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 I0UPKwMNYROy for ; Fri, 27 Mar 2009 10:11:16 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 135433A6968 for ; Fri, 27 Mar 2009 10:11:16 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2RHBvou007192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Mar 2009 12:11:58 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2RHBvit006187; Fri, 27 Mar 2009 12:11:57 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2RHBsFA006086; Fri, 27 Mar 2009 12:11:57 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 10:11:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Mar 2009 10:11:54 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105BE9572@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <421BDB40FF024D8D88FC8D7FD576E9FE@JiangXiong> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Comments on draft-jiang-incremental-cgn-00.txt Thread-Index: Acmtn0EvGxgcGCRRQay1nxItAWoG7QALm0vwABgcAiAANB7JIA== References: <49CABA6C.4000906@gmail.com><39C363776A4E8C4A94691D2BD9D1C9A105BB5267@XCH-NW-7V2.nw.nos.boeing.com> <421BDB40FF024D8D88FC8D7FD576E9FE@JiangXiong> From: "Templin, Fred L" To: "Sheng Jiang" , "Brian E Carpenter" , "Behave WG" X-OriginalArrivalTime: 27 Mar 2009 17:11:56.0044 (UTC) FILETIME=[219A8CC0:01C9AEFF] Cc: draft-jiang-incremental-cgn@tools.ietf.org Subject: Re: [BEHAVE] Comments on draft-jiang-incremental-cgn-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, 27 Mar 2009 17:11:17 -0000 Sheng, > -----Original Message----- > From: Sheng Jiang [mailto:shengjiang@huawei.com] > Sent: Thursday, March 26, 2009 9:27 AM > To: Templin, Fred L; 'Brian E Carpenter'; 'Behave WG' > Cc: draft-jiang-incremental-cgn@tools.ietf.org > Subject: [BEHAVE] ***SPAM*** 7.569 (5) =B4=F0=B8=B4: Comments on = draft-jiang-incremental-cgn-00.txt >=20 > Hi, Templin, >=20 > Thanks for your comments. When we wrote the draft, we mainly meant = traffic > went through NAT-PT after CGN aggregation. However, I also agree what = you > describe can work: NAT-PT or equivalent function can also be = integrated > within CPE. Actually, this scenario may avoid some performance issue = in CGN > by reducing the maintaining burden for stateful NAT-PT mapping. On = another > side, I am also concerned it may increase CPE's complication, and also = the > network management complication. I'm not sure that it would be so bad. The CPE already has to provide DNS services, so how bad would it be to have it also set up NAT state based on the DNS queries. The CPE is also closest to the hosts that need the service, so the fate sharing balance seems better. So, with IPv4-only hosts behind a CPE that does something like NAT-PT, wouldn't it be better to up-convert to IPv6 at the CPE itself? Fred fred.l.templin@boeing.com >=20 > Sheng >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Templin, Fred L = [mailto:Fred.L.Templin@boeing.com] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA3=D4=C226=C8=D5 13:58 > > =CA=D5=BC=FE=C8=CB: Brian E Carpenter; Behave WG > > =B3=AD=CB=CD: draft-jiang-incremental-cgn@tools.ietf.org > > =D6=F7=CC=E2: Comments on draft-jiang-incremental-cgn-00.txt > > > > This document appears to be in very good shape for a > > -00 draft, and I have only one observation for now. In > > Section 3, the sentence: "...NAT-PT [RFC2766, RFC4966] > > (or its replacement) can be integrated with CGN." - I > > am wondering here whether a NAT-PT or equivalent > > function could also reside within the Dual-Stack > > Home Gateway (HG) such that the state maintenance, > > DNS, fate sharing, etc. is kept close to the hosts? > > > > Then, let the CGN become a dual-stack IPv6 router, and > > the ISP network can be traversed via an IPv6/IPv4 tunnel. > > Consider also that tunnels could go from HG(A) to HG(B) > > within the same ISP network. Only the HGs and CGNs > > are touched while the ISP network can remain as IPv4, > > so the scenario begins to look very much like VET. > > > > In this sort of arrangement, for an IPv4-only host in > > the home network connecting to an IPv4 server in the > > Internet, the HG just lets it go as IPv4 using NAT44. > > For an IPv4-only host connecting to an IPv6 server, > > however, the HG's NAT-PT function (or equivalent) would > > establish the necessary state such that IPv4 packets > > going out are translated to IPv6, and IPv6 packets > > coming in are translated to IPv4. > > > > For an IPv6-only host in the home network connecting > > to an IPv6 server, the HG just lets it go as IPv6, > > tunneled over IPv4 in the ISP network if necessary. > > For an IPv6-only host connecting to an IPv4 server, > > however, discover the server's address ('a.b.c.d') > > and map it to a special-use IPv6 /96 prefix, e.g., as > > "f00::a.b.c.d/96". Let the CGN advertise reachability > > to "f00::/96" such that the HG's IPv6 packets are > > conveyed to the CGN. The CGN then translates the > > IPv6 packets going out into IPv4 packets, and uses > > NAT44 to forward them on to the IPv4 server (with > > IPv4-to-IPv6 translation in the reverse path). In > > this sense, "f00::/96" represents the entire IPv4 > > Internet. > > > > So, there are two seperate and complimentary NAT-PT > > (or equivalent) functions - one in the HG and one in > > the CGN - but each presents a slightly different > > service model as described above. Is this something > > like what you had in mind? > > > > Fred > > fred.l.templin@boeing.com > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > > Sent: Wednesday, March 25, 2009 4:13 PM > > > To: Behave WG > > > Cc: draft-jiang-incremental-cgn@tools.ietf.org > > > Subject: [BEHAVE] draft-jiang-incremental-cgn-00.txt > > > > > > This draft was discussed in v6ops, but the authors would be = interested > > > in comments from BEHAVE as well. We'll start working on the next > > version > > > in a couple of weeks, so please comment soon. > > > > > > The slides are at > > > http://www3.ietf.org/proceedings/09mar/slides/v6ops-7.pdf > > > > > > Brian > > > _______________________________________________ > > > 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 alain_durand@cable.comcast.com Fri Mar 27 11:37: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 8AB863A68E0 for ; Fri, 27 Mar 2009 11:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.115 X-Spam-Level: X-Spam-Status: No, score=-5.115 tagged_above=-999 required=5 tests=[AWL=3.348, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 WxBL09G2FP8k for ; Fri, 27 Mar 2009 11:37:50 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 1C15528C124 for ; Fri, 27 Mar 2009 11:37:43 -0700 (PDT) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.31539802; Fri, 27 Mar 2009 13:38:18 -0500 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 14:38:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 27 Mar 2009 14:38:01 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F6031BB332@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Plan for IPv4/IPv6 translation documents Thread-Index: Acmu5W5uzR/UOZ/hTqCbjokppIQgegAJbnM/ From: "Durand, Alain" To: , X-OriginalArrivalTime: 27 Mar 2009 18:38:18.0651 (UTC) FILETIME=[32AD9EB0:01C9AF0B] Cc: miyata@tahi.org, behave@ietf.org, fred@cisco.com, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] Plan for IPv4/IPv6 $translation 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, 27 Mar 2009 18:37:51 -0000 USMqKipxcQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBiZWhhdmUtYm91 bmNlc0BpZXRmLm9yZyA8YmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogbWFyY2VsbyBiYWdu dWxvIGJyYXVuIDxtYXJjZWxvQGl0LnVjM20uZXM+DQpDYzogQmVoYXZlIFdHIDxiZWhhdmVAaWV0 Zi5vcmc+OyBIaXJvc2hpIE1JWUFUQSA8bWl5YXRhQHRhaGkub3JnPjsgRnJlZCBCYWtlciA8ZnJl ZEBjaXNjby5jb20+OyBCZWhhdmUgQ2hhaXJzIDxiZWhhdmUtY2hhaXJzQHRvb2xzLmlldGYub3Jn Pg0KU2VudDogRnJpIE1hciAyNyAxMDowNjo1MyAyMDA5DQpTdWJqZWN0OiBSZTogW0JFSEFWRV0g UGxhbiBmb3IgSVB2NC9JUHY2IHRyYW5zbGF0aW9uIGRvY3VtZW50cw0KDQptYXJjZWxvIGJhZ251 bG8gYnJhdW4g5YaZ6YGTOg0KPiBYaW5nIExpIGVzY3JpYmnDszoNCj4+IEhpcm9zaGkgTUlZQVRB IOWGmemBkzoNCj4+PiBGcmVkLA0KPj4+DQo+Pj4gSSBhZ3JlZSBtYWtpbmcgc2VwYXJhdGUgcHJl Zml4IHJlY29tbWVuZGF0aW9uIGRvY3VtZW50LCBzaW5jZSB3ZSANCj4+PiB3b3VsZCBoYXZlIHdl bGwga25vd24NCj4+PiBwcmVmaXggZm9yIHRyYW5zbGF0b3IuDQo+Pj4gV0tQIHdvdWxkIHdvcmsg d2l0aCBzb21lIHJlc3RyaWN0aW9uLCBsaWtlIElQdjYgbmV0d29yayB0byBJUHY0IA0KPj4+IGlu dGVybmV0Lg0KPj4NCj4+IEZvciB0aGUgc3RhdGVsZXNzIHRyYW5zbGF0b3IsIHRoZSBMSVIgaXMg dGhlIG9ubHkgY2hvaWNlIHNpbmNlIHdlIA0KPj4gc2hvdWxkIG5vdCBpbnNlcnQgdGhlIGdsb2Jh bCBJUHY0IHJvdXRpbmcgdGFibGUgaW50byBnbG9iYWwgSVB2NiANCj4+IHJvdXRpbmcgc3lzdGVt Lg0KPj4NCj4gaW1obyB0aGlzIHByb2JsZW0gaXMgbm90IHJlbGF0ZWQgdG8gc3RhdGVsZXNzIG9y IHN0YXRlZnVsbCwgYnV0IA0KPiByZWxhdGVkIHRvIHdoZXRoZXIgdGhlIHNjZW5hcmlvIGludm9s dmVzIGFuIElQdjYgbmV0d29yayBvciB0aGUgSVB2NiANCj4gSW50ZXJuZXQgKGkuZS4gYnkgZGVm aW5pdGlvbiwgeW91IGNhbm5vdCBpbmplY3QgdGhlIElQdjQgcm91dGluZyB0YWJsZSANCj4gaW50 byB0aGUgSVB2NiBpbnRlcm5ldCBpZiB0aGUgc2NlbmFyaW9uIGRvZXMgbm90IGludm9sdmVzIHRo ZSBJUHY2IA0KPiBpbnRlcm5ldCkNCj4NCg0KSXQgaXMgc3Ryb25nbGUgcmVsYXRlZCB0byB0aGUg c3RhdGVsZXNzL3N0YXRlZnVsIG1vZGUuIFBsZWFzZSBzZWUgdGV4dCANCmluIHRoZSBmcmFtZXdv cmsgZG9jdW1lbnQuDQoNCjIuMi4xLiBMSVIgcHJlZml4IHZlcnN1cyBXZWxsLUtub3duIHByZWZp eA0KMi4yLjEuMS4gU3RhdGVsZXNzIG1vZGUNCjIuMi4xLjEuMS4gSVB2NiBSb3V0aW5nIHN5c3Rl bSBzY2FsYWJpbGl0eQ0KDQoNCiAgIEluIHRoZSBzdGF0ZWxlc3MgbW9kZSwgdGhlIG1vcmUgc3Bl Y2lmaWNzIGluc2lkZSB0aGUgSVB2NC1lbWJlZGRlZA0KICAgSVB2NiBhZGRyZXNzIGJsb2NrIGFy ZSB1c2VkIHRvIHJlcHJlc2VudCB0aGUgSVB2NiBlbmQgc3lzdGVtcywNCiAgIHRoZXJlZm9yZSB0 aGUgTElSIHByZWZpeCBzaG91bGQgYmUgdXNlZC4gIFRoZSByZWFzb24gaXMgdGhhdCB0aGUgTElS DQogICBwcmVmaXggY2FuIGJlIGFnZ3JlZ2F0ZWQgaW4gdGhlIElTUCdzIGJvcmRlciByb3V0ZXJz IGFuZCB3aWxsIG5vdA0KICAgYWZmZWN0IHRoZSBnbG9iYWwgSVB2NiByb3V0aW5nIHN5c3RlbS4g IE9uIHRoZSBvdGhlciBoYW5kLCBpZiB0aGUNCiAgIFdlbGwtS25vd24gcHJlZml4IGlzIHVzZWQs IHRoZSBnbG9iYWwgSVB2NCByb3V0aW5nIHRhYmxlIHdpbGwgYmUNCiAgIGluc2VydGVkIGludG8g dGhlIGdsb2JhbCBJUHY2IHJvdXRpbmcgc3lzdGVtLCB3aGljaCBpcyBrbm93biB0byBiZSBhDQog ICB2ZXJ5IGJhZCBpZGVhLg0KDQogICBJbiB0aGUgc3RhdGVsZXNzIG1vZGUsIGl0IGlzIHBvc3Np YmxlIHRvIHVzZSBMSVIgcHJlZml4IHRvIHJlcHJlc2VudA0KICAgdGhlIElQdjYgYWRkcmVzc2Vz IGluIHRoZSBJUHY0IEludGVybmV0IGFuZCB1c2UgV2VsbC1Lbm93biBwcmVmaXggdG8NCiAgIHJl cHJlc2VudCB0aGUgSVB2NCBhZGRyZXNzZXMgaW4gdGhlIElQdjYgSW50ZXJuZXQuICBIb3dldmVy LCB0aGlzIGlzDQogICBhbHNvIGEgYmFkIGlkZWEuICBUaGUgcmVhc29uIGlzIHRoYXQgdGhlcmUg d2lsbCBiZSB0d28gcG9zc2libGUgSVB2Ng0KICAgYWRkcmVzc2VzIHRvIHJlcHJlc2VudCBhIHNp bmdsZSBJUHY0IGhvc3QsIGkuZS4gaWYgdGhlIElQdjQgYWRkcmVzcw0KICAgaXMgdXNlZCBieSBh IGhvc3QgaW4gdGhlIElQdjQgSW50ZXJuZXQsIGEgV2VsbC1Lbm93biBwcmVmaXggc2hvdWxkIGJl DQogICB1c2VkOyBpZiB0aGUgSVB2NCBhZGRyZXNzIChhcyBJVkk2KSBpcyB1c2VkIGJ5IGEgaG9z dCBpbiB0aGUgSVB2Ng0KICAgSW50ZXJuZXQsIGEgTElSIHByZWZpeCBzaG91bGQgYmUgdXNlZC4g IFRoZSBJVkk2IGhvc3RzIG11c3Qga25vdw0KICAgd2hpY2ggb25lIHRvIHVzZSBpbiBvcmRlciB0 byBjb21tdW5pY2F0ZSB3aXRoIHRoYXQgaG9zdC4gIEhvd2V2ZXIsIGlmDQogICB0aGUgTElSIHBy ZWZpeCBpcyB1c2VkIGluIGJvdGggcmVwcmVzZW50YXRpb25zLCB0aGlzIHByb2JsZW0gaXMNCiAg IHNvbHZlZCBieSB0aGUgIm1vcmUgc3BlY2lmaWMgd2luIiByb3V0aW5nIHByaW5jaXBsZS4NCg0K ICAgVGhlIHBvdGVudGlhbCBsZWFrYWdlIG9mIHRoZSBJUHY2IG1vcmUgc3BlY2lmaWNzIGludHJv ZHVjZWQgYnkgdXNpbmcNCiAgIExJUiBwcmVmaXggY291bGQgYmUgY29udHJvbGxlZCBieSBJU1An cyBnZW5lcmFsIHJvdXRpbmcgcHJhY3RpY2UsDQogICBzaW5jZSB0aGlzIHNwZWNpZmljIGlzIHRo ZSBzYW1lIGNvbXBhcmVkIHdpdGggb3RoZXIgbW9yZSBzcGVjaWZpY3MNCiAgIGluc2lkZSBJU1An cyBhdXRvbm9tb3VzIHN5c3RlbS4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YmFrZXItYmVoYXZlLXY0djYtZnJhbWV3b3JrLTAyDQoNCnJlZ2FyZHMsDQoNCnhpbmcNCg0KPiBy ZWdhcmRzLCBtYXJjZWxvDQo+DQo+Pj4NCj4+Pg0KPj4+IFdoaWNoIGRvY3VtZW50IHdlIHNob3Vs ZCBiYXNlZCBvbiBpcyBhbm90aGVyIGRpc2N1c3Npb24uIDstKQ0KPj4+DQo+PiBJbiB0aGUgZHJh ZnQtYmFrZXItYmVoYXZlLXY0djYtZnJhbWV3b3JrLTAyLnR4dCwgaXQgc3VtbWFyaXplcyBib3Ro IA0KPj4gdGhlIHN0YXRlbGVzcyBhbmQgdGhlIHN0YXRlZnVsIG1vZGVzIG9mIHRoZSB0cmFuc2xh dG9yLCB3aGlsZSB0aGUgDQo+PiBvdGhlcnMgb25seSBhZGRyZXNzIHRoZSBzdGF0ZWZ1bCBtb2Rl Lg0KPj4NCj4+IHhpbmcNCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IEJlaGF2ZSBtYWlsaW5nIGxpc3QNCj4+IEJlaGF2ZUBpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUNCj4N Cj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJl aGF2ZSBtYWlsaW5nIGxpc3QNCkJlaGF2ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9iZWhhdmUNCg== From alain_durand@cable.comcast.com Fri Mar 27 11:58: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 B041C3A6CB7 for ; Fri, 27 Mar 2009 11:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[AWL=-3.691, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6-xKST0cM+L for ; Fri, 27 Mar 2009 11:58:30 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 0DE833A6857 for ; Fri, 27 Mar 2009 11:58:29 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.68302856; Fri, 27 Mar 2009 14:59:03 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 14:59:03 -0400 Received: from 10.17.2.194 ([10.17.2.194]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 Mar 2009 18:58:56 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 27 Mar 2009 11:58:51 -0700 From: "Durand, Alain" To: Alain Durand , , Message-ID: Thread-Topic: [BEHAVE] Plan for IPv4/IPv6 $translation documents Thread-Index: Acmu5W5uzR/UOZ/hTqCbjokppIQgegAJbnM/AAC6Pws= In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F6031BB332@PACDCEXCMB06.cable.comcast.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3320999932_80399" X-OriginalArrivalTime: 27 Mar 2009 18:59:03.0245 (UTC) FILETIME=[188397D0:01C9AF0E] Cc: behave@ietf.org, miyata@tahi.org, fred@cisco.com, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] Plan for IPv4/IPv6 $translation 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, 27 Mar 2009 18:58:31 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3320999932_80399 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable I apologize for this message my new phone thought it should sent for me. - Alain. On 3/27/09 11:38 AM, "Alain Durand" wrote: > Q#***qq >=20 > ----- Original Message ----- > From: behave-bounces@ietf.org > To: marcelo bagnulo braun > Cc: Behave WG ; Hiroshi MIYATA ; Fred B= aker > ; Behave Chairs > Sent: Fri Mar 27 10:06:53 2009 > Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation documents >=20 > marcelo bagnulo braun =D0=B4=B5=C0: >> > Xing Li escribi=A8=AE: >>> >> Hiroshi MIYATA =D0=B4=B5=C0: >>>> >>> Fred, >>>> >>> >>>> >>> I agree making separate prefix recommendation document, since we >>>> >>> would have well known >>>> >>> prefix for translator. >>>> >>> WKP would work with some restriction, like IPv6 network to IPv4 >>>> >>> internet. >>> >> >>> >> For the stateless translator, the LIR is the only choice since we >>> >> should not insert the global IPv4 routing table into global IPv6 >>> >> routing system. >>> >> >> > imho this problem is not related to stateless or statefull, but >> > related to whether the scenario involves an IPv6 network or the IPv6 >> > Internet (i.e. by definition, you cannot inject the IPv4 routing table >> > into the IPv6 internet if the scenarion does not involves the IPv6 >> > internet) >> > >=20 > It is strongle related to the stateless/stateful mode. Please see text > in the framework document. >=20 > 2.2.1. LIR prefix versus Well-Known prefix > 2.2.1.1. Stateless mode > 2.2.1.1.1. IPv6 Routing system scalability >=20 >=20 > In the stateless mode, the more specifics inside the IPv4-embedded > IPv6 address block are used to represent the IPv6 end systems, > therefore the LIR prefix should be used. The reason is that the LIR > prefix can be aggregated in the ISP's border routers and will not > affect the global IPv6 routing system. On the other hand, if the > Well-Known prefix is used, the global IPv4 routing table will be > inserted into the global IPv6 routing system, which is known to be a > very bad idea. >=20 > In the stateless mode, it is possible to use LIR prefix to represent > the IPv6 addresses in the IPv4 Internet and use Well-Known prefix to > represent the IPv4 addresses in the IPv6 Internet. However, this is > also a bad idea. The reason is that there will be two possible IPv6 > addresses to represent a single IPv4 host, i.e. if the IPv4 address > is used by a host in the IPv4 Internet, a Well-Known prefix should be > used; if the IPv4 address (as IVI6) is used by a host in the IPv6 > Internet, a LIR prefix should be used. The IVI6 hosts must know > which one to use in order to communicate with that host. However, if > the LIR prefix is used in both representations, this problem is > solved by the "more specific win" routing principle. >=20 > The potential leakage of the IPv6 more specifics introduced by using > LIR prefix could be controlled by ISP's general routing practice, > since this specific is the same compared with other more specifics > inside ISP's autonomous system. >=20 > http://tools.ietf.org/html/draft-baker-behave-v4v6-framework-02 >=20 > regards, >=20 > xing >=20 >> > regards, marcelo >> > >>>> >>> >>>> >>> >>>> >>> Which document we should based on is another discussion. ;-) >>>> >>> >>> >> In the draft-baker-behave-v4v6-framework-02.txt, it summarizes both >>> >> the stateless and the stateful modes of the translator, while the >>> >> others only address the stateful mode. >>> >> >>> >> xing >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >=20 --B_3320999932_80399 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable Re: [BEHAVE] Plan for IPv4/IPv6 $translation documents I apologize for this message my new phone thought it should sent for me.
  - Alain.


On 3/27/09 11:38 AM, "Alain Durand" <Alain_Durand@cable.comcast.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Q#***qq

----- Original Message -----
From: behave-bounces@ietf.org <behave-bounces@ietf.org>
To: marcelo bagnulo braun <marcelo@it.uc3m.= es>
Cc: Behave WG <behave@ietf.org>; Hirosh= i MIYATA <miyata@tahi.org>; Fred Baker &= lt;fred@cisco.com>; Behave Chairs <behave-chairs@tools.ietf.org>
Sent: Fri Mar 27 10:06:53 2009
Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation documents

marcelo bagnulo braun =D0=B4=B5=C0:
> Xing Li escribió:
>> Hiroshi MIYATA =D0=B4=B5=C0:
>>> Fred,
>>>
>>> I agree making separate prefix recommendation document, since = we
>>> would have well known
>>> prefix for translator.
>>> WKP would work with some restriction, like IPv6 network to IPv= 4
>>> internet.
>>
>> For the stateless translator, the LIR is the only choice since we<= BR> >> should not insert the global IPv4 routing table into global IPv6 >> routing system.
>>
> imho this problem is not related to stateless or statefull, but
> related to whether the scenario involves an IPv6 network or the IPv6 > Internet (i.e. by definition, you cannot inject the IPv4 routing table=
> into the IPv6 internet if the scenarion does not involves the IPv6
> internet)
>

It is strongle related to the stateless/stateful mode. Please see text
in the framework document.

2.2.1. LIR prefix versus Well-Known prefix
2.2.1.1. Stateless mode
2.2.1.1.1. IPv6 Routing system scalability


   In the stateless mode, the more specifics inside the IPv4= -embedded
   IPv6 address block are used to represent the IPv6 end sys= tems,
   therefore the LIR prefix should be used.  The reason= is that the LIR
   prefix can be aggregated in the ISP's border routers and = will not
   affect the global IPv6 routing system.  On the other= hand, if the
   Well-Known prefix is used, the global IPv4 routing table = will be
   inserted into the global IPv6 routing system, which is kn= own to be a
   very bad idea.

   In the stateless mode, it is possible to use LIR prefix t= o represent
   the IPv6 addresses in the IPv4 Internet and use Well-Know= n prefix to
   represent the IPv4 addresses in the IPv6 Internet.  = However, this is
   also a bad idea.  The reason is that there will be t= wo possible IPv6
   addresses to represent a single IPv4 host, i.e. if the IP= v4 address
   is used by a host in the IPv4 Internet, a Well-Known pref= ix should be
   used; if the IPv4 address (as IVI6) is used by a host in = the IPv6
   Internet, a LIR prefix should be used.  The IVI6 hos= ts must know
   which one to use in order to communicate with that host. =  However, if
   the LIR prefix is used in both representations, this prob= lem is
   solved by the "more specific win" routing princ= iple.

   The potential leakage of the IPv6 more specifics introduc= ed by using
   LIR prefix could be controlled by ISP's general routing p= ractice,
   since this specific is the same compared with other more = specifics
   inside ISP's autonomous system.

h= ttp://tools.ietf.org/html/draft-baker-behave-v4v6-framework-02

regards,

xing

> regards, marcelo
>
>>>
>>>
>>> Which document we should based on is another discussion. ;-) >>>
>> In the draft-baker-behave-v4v6-framework-02.txt, it summarizes bot= h
>> the stateless and the stateful modes of the translator, while the<= BR> >> others only address the stateful mode.
>>
>> 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
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org= /mailman/listinfo/behave

--B_3320999932_80399-- From David.Miles@alcatel-lucent.com.au Fri Mar 27 17:26: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 7D36B3A6859; Fri, 27 Mar 2009 17:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 AP+0mdrvRCgW; Fri, 27 Mar 2009 17:26:23 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 949283A67F8; Fri, 27 Mar 2009 17:26:23 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n2S0RHFF010515; Fri, 27 Mar 2009 19:27:17 -0500 (CDT) Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n2S0RFtU024945; Fri, 27 Mar 2009 19:27:16 -0500 (CDT) Received: from sgsinsbhs01.ad4.ad.alcatel.com (sgsinsbhs01.ap.lucent.com [135.254.109.34]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id n2S0QF3E025193; Sat, 28 Mar 2009 08:26:15 +0800 Received: from SGSINSMBS02.ad4.ad.alcatel.com ([135.254.109.30]) by sgsinsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Mar 2009 08:27:14 +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: Sat, 28 Mar 2009 08:27:08 +0800 Message-ID: <986DCE2E44129444B6435ABE8C9E424D02F7E95D@SGSINSMBS02.ad4.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [shara] Follow up on Layer2-Aware NAT (draft-miles-behave-l2nat-00) Thread-Index: AcmgdlhcsqF9XOaRSFmUv5LfTG7d5QAAEU/wA2dPQ2AASTlpgA== References: <986DCE2E44129444B6435ABE8C9E424D02D5CE0A@SGSINSMBS02.ad4.ad.alcatel.com> From: "MILES DAVID" To: , , X-OriginalArrivalTime: 28 Mar 2009 00:27:14.0285 (UTC) FILETIME=[F149D9D0:01C9AF3B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130 Subject: Re: [BEHAVE] [shara] Follow up on Layer2-Aware NAT (draft-miles-behave-l2nat-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, 28 Mar 2009 00:26:24 -0000 Pierre, Thanks for the support. The presentation of draft-nishitani-cgn-01 outlined a good way forward - here the Network Model was separated from the core NAT Function. I think a L2-Aware NAT best belongs in a core document like this. In this way L2-Aware NAT could make up an optional component of the core NAT Function (in the way it describes a Virtual NAT [tables] facility). On top of this a variety of network models could be created and documented - these could even come from other working groups (such as Softwires).I believe a core NAT function (regardless of whether we describe IPv4 or IPv6) fits well in BEHAVE.=20 Applying the mechanisms in L2-Aware NAT to PRR makes a lot of sense as well - I'm wondering if port-range solutions could be described (perhaps poorly) as similar to a NAPT mapping function (outside-ip/port to inside-ip/port) however in the case of PRR, the pairs are the same/common - in effect a address/port translation does not occur. What do you think of attempting to describe the PRR function like this? If agreeable I would like to invite the authors of PRR/A+P and CGN drafts to work within the bounds of a new draft that describes a core NAT function (without drawing reference to size or scale) - introducing elements of core NAT function (CGN/LSN) virtual NAPT tables (L2-Aware NAT), and mappings tables where translation is not applied (PRR). Best Regards, -David -----Original Message----- From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf Of pierre.levis@orange-ftgroup.com Sent: Thursday, March 26, 2009 6:17 AM To: behave@ietf.org; shara@ietf.org Subject: [shara] Follow up on Layer2-Aware NAT (draft-miles-behave-l2nat-00) The comment I had on the mike during behave session 2: This kind of work is very valuable, it is worth not only for CGN but also for Port Ranges solutions and for all IPv4 shortage solutions.=20 As we presented it in the shara BoF all solutions basically: 1) Put a dedicated function in an ISP Box (CGN, PRR, whatever) 2) Use some sort of transport mechanism (tunneling, layer 2, whatever) between customers and ISPBox,=20 3) Are confronted with the same issues: how to force a route from customers to ISPBox, how to route back from ISPBox to relevant customer, how to identify the customer.=20 This would advocate for seeing all work related to IPv4 shared addresses host in the same place, under the same ombrella. =20 Regards Pierre _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From xing@cernet.edu.cn Sat Mar 28 07: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 31C093A6905 for ; Sat, 28 Mar 2009 07:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.03 X-Spam-Level: X-Spam-Status: No, score=0.03 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 8ywIa5qMeAvN for ; Sat, 28 Mar 2009 07:04:41 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 6535D3A6837 for ; Sat, 28 Mar 2009 07:04:39 -0700 (PDT) Received: from [127.0.0.1]([123.112.69.177]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jma49ce9a20; Sat, 28 Mar 2009 22:05:32 +0800 Message-ID: <49CE2E9D.3040004@cernet.edu.cn> Date: Sat, 28 Mar 2009 22:05:17 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Brian E Carpenter References: <67DFA2B0-AC2A-4E02-86B5-DDF30BB40CA1@tahi.org> <49CB85A9.6090903@cernet.edu.cn> <49CB9763.4060705@it.uc3m.es> <49CCDD7D.3000704@cernet.edu.cn> <49CCE6F4.5020903@gmail.com> In-Reply-To: <49CCE6F4.5020903@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: g0MK9nVB Cc: Hiroshi MIYATA , Behave WG , Fred Baker , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Sat, 28 Mar 2009 14:04:42 -0000 Brian E Carpenter 写é“: > > Agreed that it would be a very bad idea. But I don't understand > why it would happen. It doesn't happen with 2002::/8. > Actually the analysis in RFC3056 states that this WKP can only be used > safely if the IPv4 network is not fragmented, i.e. you MUST NOT > use 6to4 after the IPv4 global routing breaks up (in 500 years > from now?). There would need to be a similar rule for a NAT64 WKP, > I think. > > > And the same practice would need to be used for the WKP: more specifics > not allowed. BTW that might recreate some of the black hole issues > we see for 6to4. So maybe a WKP is not such a good idea. > > Brian > > > I see the point now. But in the stateless mode, the effect to the global IPv6 Internet makes the difference. For the IPv6 Internet to an IPv4-network scenario, the WKP doesn't work if the IPv4 is using private IPv4 addresses. With public IPv4 addresses, each IPv4 site will inject a route in the IPv6 routing table, i.e. importing IPv4 routing table entropy into IPv6 routing table. Therefore, the LIR should be selected. For "an IPv4 network to IPv4 Internet" scenario, as shown in the following Figure, the stateless and stateful mode should be discussed separately" ------ ----- ------ / The \ ----- / An \ / The \ | IPv4 |-----|Xlate|------| IPv6 |-----| IPv6 | \Internet/ ----- \Network/ \Internet/ ------ ----- ------ A B Figure: An IPv4 network to IPv4 Internet 1. If Xlate is stateless, "an IPv6 network" will consist of hosts using IVI6 addresses (more specifics of the IPv4 embedded IPv6 addresses). The IVI6 hosts can communicate with both the global IPv4 Internet and the global IPv6 Internet. The stateless Xlate supports both IPv6 initiated communication and the IPv4 initiated communications. 1.1 In border A, "an IPv6 network" will advertise IVI6 addresses to the Xlate and the Xlate will advertise the IPv4 embedded IPv6 addresses corresponding to 0.0.0.0/0 to "an IPv6 network". 1.2 In border B, "an IPv6 network" will advertise IVI6 addresses with proper aggregation to the IPv6 Internet and the IPv6 Internet will advertise the global IPv6 routing table or 2000::/3 to "an IPv6 network". In other words, "an IPv6 network" should advertise the aggregated prefix of "an IPv6 network" and should neither advertise the IPv4 embedded IPv6 addresses corresponding to 0.0.0.0/0 nor IVI6. This can be achieved easily if LIR is used, but cannot be achieved if WKP is used, since WKP is independent of the aggregated prefix of "an IPv6 network". In the case when WKP is used, the IVI6 must be advertised to the IPv6 Internet in order to communicate with other IPv6 hosts in the IPv6 Internet and this advertisement will eventually result in the injecting of the global IPv4 routing table into the global IPv6 routing system. 2. If Xlate is stateful, "an IPv6 network" will consist of ordinary IPv6 addresses and Xlate maintains session-initiated states to map between ordinary IPv6 addresses and the IPv4 addresses in the IPv4 address pool. The stateful Xlate only supports IPv6 initiated communication. 2.1 In border A, "an IPv6 network" will advertise the aggregated prefix of "an IPv6 network" to the Xlate and the Xlate will advertise the IPv4 embedded IPv6 addresses corresponding to 0.0.0.0/0 to "an IPv6 network". 2.2 In border B, "an IPv6 network" will advertise the aggregated prefix of "an IPv6 network" to the IPv6 Internet and the IPv6 Internet will advertise the global IPv6 routing table or 2000::/3 to "an IPv6 network". There is no need to advertise the IPv4 embedded IPv6 addresses corresponding to 0.0.0.0/0 to the IPv6 Internet, if translation service of "an IPv6 Internet" is not supported to other IPv6 networks. Therefore, the selection of WKP versus LIR is mainly the operational consideration. Please comment. xing From xing@cernet.edu.cn Sat Mar 28 07:08: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 7CF603A68F7 for ; Sat, 28 Mar 2009 07:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.037 X-Spam-Level: X-Spam-Status: No, score=0.037 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 SeGHmpWpLuCq for ; Sat, 28 Mar 2009 07:08:43 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id E6CFD3A687B for ; Sat, 28 Mar 2009 07:08:42 -0700 (PDT) Received: from [127.0.0.1]([123.112.69.177]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm3849ce9b13; Sat, 28 Mar 2009 22:09:35 +0800 Message-ID: <49CE2F9F.9080306@cernet.edu.cn> Date: Sat, 28 Mar 2009 22:09:35 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fred Baker References: <67DFA2B0-AC2A-4E02-86B5-DDF30BB40CA1@tahi.org> <49CB85A9.6090903@cernet.edu.cn> <49CB9763.4060705@it.uc3m.es> <49CCDD7D.3000704@cernet.edu.cn> 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: g7HO9nVB Cc: Hiroshi MIYATA , congxiao , Behave WG , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Sat, 28 Mar 2009 14:08:44 -0000 Fred Baker 写é“: > I think you guys are speaking at cross purposes. Let me try to > disambiguate. > > Xing Li, your point is that the IPv4-in-IPv6 more specifics in the IVI > network you run represent individual customers, and are aggregated > into the common prefix on the IPv4 side of the translator, and that > the entire IPv4 space is aggregated into what amounts to a default > route on the IPv6 side. Your comment that IPv4 more-specifics should > generally not be brought into the IPv6 network. Right? Yes. > > Marcelo, Your point about injecting the IPv4 Internet routing into "an > IPv6 network" vs "the IPv6 Internet" is about the connectivity of that > IPv6 network - we're only talking about the IPv6 Internet if the > network in question is distributing routes throughout that network. > > > Guys, please. > > > As far as peering, CERNET2 peers with networks in the US,. Europe, and > Japan. CERNET2 is part of the emerging IPv6 Internet. There is no call > to say otherwise. > > As to the issue of injection of routes, if CERNET2 was using a magic > prefix, it would not advertise that (or the IPv4 routes it would > imply) to its IPv6 neighbors, and one hopes that if it erroneously did > so its neighbors would refuse the route. So in that case it would not > provide IPv4 connectivity to its peers. However, if it is simply > advertising its own prefix to its peers, it in effect is offering > transit service to its IPv4-mapped prefix (which is part of its LIR > prefix). I would imagine that CERNET2 advertises a set of > less-specifics that in fact don't offer transit to the IPv4 network. Yes. Thanks for the comments. xing > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From randy@psg.com Sat Mar 28 14:52: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 1A2743A6B80; Sat, 28 Mar 2009 14:52:23 -0700 (PDT) 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 m6eqFnKqdh1d; Sat, 28 Mar 2009 14:52:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 2706F3A6B75; Sat, 28 Mar 2009 14:52:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.om) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LngSo-000Ada-3w; Sat, 28 Mar 2009 21:53:14 +0000 Received: from dhcp-17e8.meeting.ietf.org.psg.com (localhost [127.0.0.1]) by rmac.psg.om (Postfix) with ESMTP id 3E28F55A9AD; Sat, 28 Mar 2009 14:53:13 -0700 (PDT) Date: Sat, 28 Mar 2009 14:53:08 -0700 Message-ID: From: Randy Bush To: "MILES DAVID" In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D02F7E95D@SGSINSMBS02.ad4.ad.alcatel.com> References: <986DCE2E44129444B6435ABE8C9E424D02D5CE0A@SGSINSMBS02.ad4.ad.alcatel.com> <986DCE2E44129444B6435ABE8C9E424D02F7E95D@SGSINSMBS02.ad4.ad.alcatel.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: behave@ietf.org, pierre.levis@orange-ftgroup.com, shara@ietf.org Subject: Re: [BEHAVE] [shara] Follow up on Layer2-Aware NAT (draft-miles-behave-l2nat-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, 28 Mar 2009 21:52:23 -0000 > If agreeable I would like to invite the authors of PRR/A+P and CGN > drafts to work within the bounds of a new draft that describes a core > NAT function (without drawing reference to size or scale) - introducing > elements of core NAT function (CGN/LSN) virtual NAPT tables (L2-Aware > NAT), and mappings tables where translation is not applied (PRR). hmmmm. have you read the latest a+p i-d? randy From gaborbajko@gmail.com Sun Mar 29 11:01: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 17FDE3A6832; Sun, 29 Mar 2009 11:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qe3KRk6bQhN; Sun, 29 Mar 2009 11:01:23 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 2CC4C3A6BE0; Sun, 29 Mar 2009 11:01:23 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2207710wfg.31 for ; Sun, 29 Mar 2009 11:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references:subject :date:message-id:mime-version:content-type:content-transfer-encoding :x-mailer:in-reply-to:thread-index:x-mimeole; bh=jravn/zGPItFMYLZulxbGVmwJPKoyPB+45NFusMOyj8=; b=hEav0hWKxDUrQrsQRySu+kwKlfsrM852uloMXFfBaID2IrVf7DfPRndvW4W8+yL/JC 4xz+1z6677hDCC3h+oCnhkB6vYsEWLjjTRi1dTxbFTOyPeFyeXKV5pZQDchlaqn/JISy 77n7YA1VQLIyfSf48g2etCb7z/nuOXAunUuJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; b=b/GJMxCfzJLM2CDzRvuircFu8xWPEflZ5h67BG/SiuUjcg/BqIXF20BehLA8U/j/MZ JmR+CFNlWw2s43FwQJPW+iaDd9AOzO40RgrMEPitZhoQoQ8JDmChm5KQC5+iGvrJNKNA KNHT9jhmdtGlVnm7Zc4hJX+DpOqYufsXWgjiE= Received: by 10.142.134.17 with SMTP id h17mr1776980wfd.206.1238349740368; Sun, 29 Mar 2009 11:02:20 -0700 (PDT) Received: from 1USL00618 (c-67-169-182-244.hsd1.ca.comcast.net [67.169.182.244]) by mx.google.com with ESMTPS id 30sm7147094wfc.44.2009.03.29.11.02.18 (version=SSLv3 cipher=RC4-MD5); Sun, 29 Mar 2009 11:02:19 -0700 (PDT) From: "Gabor Bajko" To: "'MILES DAVID'" , , , References: <986DCE2E44129444B6435ABE8C9E424D02D5CE0A@SGSINSMBS02.ad4.ad.alcatel.com> <986DCE2E44129444B6435ABE8C9E424D02F7E95D@SGSINSMBS02.ad4.ad.alcatel.com> Date: Sun, 29 Mar 2009 11:02:16 -0700 Message-ID: <021601c9b098$801cabd0$c2158182@NOE.Nokia.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: <986DCE2E44129444B6435ABE8C9E424D02F7E95D@SGSINSMBS02.ad4.ad.alcatel.com> Thread-Index: AcmgdlhcsqF9XOaRSFmUv5LfTG7d5QAAEU/wA2dPQ2AASTlpgABXncyQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [BEHAVE] [shara] Follow up on Layer2-Aware NAT(draft-miles-behave-l2nat-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: Sun, 29 Mar 2009 18:01:24 -0000 There were a number of inconsistencies on the comparison slide (eg, that IPv4 traffic is subject to NAPT in case of A+P, etc). It has to be clearly stated that what this solution offers is a technological dead-end, as there is no evolution path away from IPv4 in it. - gabor >-----Original Message----- >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf >Of MILES DAVID >Sent: Friday, March 27, 2009 5:27 PM >To: pierre.levis@orange-ftgroup.com; behave@ietf.org; shara@ietf.org >Subject: Re: [BEHAVE] [shara] Follow up on Layer2-Aware NAT(draft-miles- >behave-l2nat-00) > >Pierre, > >Thanks for the support. The presentation of draft-nishitani-cgn-01 >outlined a good way forward - here the Network Model was separated from >the core NAT Function. I think a L2-Aware NAT best belongs in a core >document like this. >In this way L2-Aware NAT could make up an optional component of the core >NAT Function (in the way it describes a Virtual NAT [tables] facility). >On top of this a variety of network models could be created and >documented - these could even come from other working groups (such as >Softwires).I believe a core NAT function (regardless of whether we >describe IPv4 or IPv6) fits well in BEHAVE. > >Applying the mechanisms in L2-Aware NAT to PRR makes a lot of sense as >well - I'm wondering if port-range solutions could be described (perhaps >poorly) as similar to a NAPT mapping function (outside-ip/port to >inside-ip/port) however in the case of PRR, the pairs are the >same/common - in effect a address/port translation does not occur. What >do you think of attempting to describe the PRR function like this? > >If agreeable I would like to invite the authors of PRR/A+P and CGN >drafts to work within the bounds of a new draft that describes a core >NAT function (without drawing reference to size or scale) - introducing >elements of core NAT function (CGN/LSN) virtual NAPT tables (L2-Aware >NAT), and mappings tables where translation is not applied (PRR). > >Best Regards, > >-David > >-----Original Message----- >From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf >Of pierre.levis@orange-ftgroup.com >Sent: Thursday, March 26, 2009 6:17 AM >To: behave@ietf.org; shara@ietf.org >Subject: [shara] Follow up on Layer2-Aware NAT >(draft-miles-behave-l2nat-00) > >The comment I had on the mike during behave session 2: > >This kind of work is very valuable, it is worth not only for CGN but >also for Port Ranges solutions and for all IPv4 shortage solutions. >As we presented it in the shara BoF all solutions basically: >1) Put a dedicated function in an ISP Box (CGN, PRR, whatever) >2) Use some sort of transport mechanism (tunneling, layer 2, whatever) >between customers and ISPBox, >3) Are confronted with the same issues: how to force a route from >customers to ISPBox, how to route back from ISPBox to relevant customer, >how to identify the customer. > >This would advocate for seeing all work related to IPv4 shared addresses >host in the same place, under the same ombrella. > > >Regards > >Pierre >_______________________________________________ >shara mailing list >shara@ietf.org >https://www.ietf.org/mailman/listinfo/shara >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From philip_matthews@magma.ca Sun Mar 29 11:17: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 AE4BC3A6C0D for ; Sun, 29 Mar 2009 11:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 A0TqGIjdilds for ; Sun, 29 Mar 2009 11:17:19 -0700 (PDT) Received: from mail-09.primus.ca (mail11.primus.ca [216.254.141.178]) by core3.amsl.com (Postfix) with ESMTP id A5E393A6C06 for ; Sun, 29 Mar 2009 11:17:19 -0700 (PDT) Received: from 173-17-118-183.client.mchsi.com ([173.17.118.183]) by mail-09.primus.ca with esmtpa (Exim 4.69) (envelope-from ) id 1LnzaK-0001LT-0E; Sun, 29 Mar 2009 14:18:16 -0400 Message-Id: <7CCEA676-DC64-4CE6-A3BF-D5F7605C2A5F@magma.ca> From: Philip Matthews To: Fred Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 29 Mar 2009 11:18:13 -0700 References: X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - 173-17-118-183.client.mchsi.com [173.17.118.183] Cc: Behave WG , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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: Sun, 29 Mar 2009 18:17:20 -0000 I would like to propose a variation on Fred's proposal. Specifically, I would like the "IP/ICMP Translation" document (which I will call "SIITbis") to NOT refer to the other documents, but to stand on its own. The current SIIT document has proven very useful in a variety of contexts, and I would like to keep that generality in the updated version. (For example, draft-ietf-behave-turn-v6 currently refers to SIIT, but is somewhat unrelated to the documents below.) This means that SIITbis would have normative dependencies only on existing RFCs, and thus not get delayed by other documents. For that reason, I would like to break out the Stateless translation stuff into a separate document (to be perhaps based on draft-baker- behave-ivi). The following diagram may explain this better: +---------------+ +------------------+ | Stateful | | Stateless | | nat64 | | ivi | +---------------+ +------------------+ | \ / | | --------\ /....... | v ....../ \--------- | +---------------v----+ +---v----v---------+ | SIITbis | | Prefix | | | | | +--------------------+ +------------------+ (Arrows are difficult to draw in ASCII art, but this shows the Stateful and Stateless translation documents as having normative dependencies on the SIITbis and Prefix documents, but no reverse pointers. Furthermore, draft-ietf-behave-turn-v6 may have a normative dependency on SIITbis, but not on the other documents). IN PRACTICE, this means that SIITbis should do the following: * Have no normative dependencies on any document not currently published as an RFC; * Say that "this is not a complete specification, and any document using this specification must provide certain information which is deliberately left unspecified"; * Whenever it talks about address or port or ICMP identifier field translation, simply state "the details of how this field is translated is left to the document using this specification". Then the Stateful and Stateless translation documents will fill in the blanks left in SIITbis. Comments? - Philip On Wed, 25-Mar-09, at 12:05 , Fred Baker wrote: > Referring to the October discussion and the chair's slides > yesterday, and further to private email among the framework authors, > the chairs, and Magnus yesterday and today, I want to capture what I > understand to be the documentation plan. If I have it wrong, I would > like to know that now; if I have it right I am already in process > and want confirmation of the fact. > > One thing discussed privately is that the reference from the > translation document to the prefix is normative, which means that > the document referred to should be standards track. You asked me to > pull the prefix into a separate document. > > So I understand that we have six documents called for at this point, > with possible future ALG documents, for which I am suggesting > appropriate monikers: > > IPv4/IPv6 Translation Framework > Informational, based on draft-baker-behave-v4v6-framework-02.txt > draft-ietf-behave-v4v6-framework-00.txt > IPv4/IPv6 Translation Prefix recommendation > Standards track, based on draft-baker-behave-v4v6-framework-02.txt > draft-ietf-behave-v4v6-prefix-00.txt > IP/ICMP Translation > Standards track, based on draft-baker-behave-v4v6- > translation-02.txt > draft-ietf-behave-v4v6-translation-00.txt > IPv4/IPv6 Stateful Translation Database Maintenance > Standards track, based on draft-bagnulo-behave-nat64-03.txt > draft-ietf-behave-v4v6-database-00.txt > IPv4/IPv6 DNS Translation Database Algorithm and Gateway > Standards track, based on draft-bagnulo-behave-dns64-02.txt > draft-ietf-behave-v4v6-dns-00.txt > IPv4/IPv6 FTP Application Layer Gateway > Standards Track, to be determined > > Am I correct? > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From fred@cisco.com Sun Mar 29 17:38: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 A7AD53A6B31 for ; Sun, 29 Mar 2009 17:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.424 X-Spam-Level: X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m--Oxiz21V5F for ; Sun, 29 Mar 2009 17:38:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 608883A67F2 for ; Sun, 29 Mar 2009 17:38:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,443,1233532800"; d="scan'208";a="276346994" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2009 00:39:42 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2U0dgOW023153; Sun, 29 Mar 2009 17:39:42 -0700 Received: from [10.242.56.95] (sjc-vpn2-571.cisco.com [10.21.114.59]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2U0dgqd003637; Mon, 30 Mar 2009 00:39:42 GMT Message-Id: <07600313-D7B8-4E82-94D5-9306C9F3033D@cisco.com> From: Fred Baker To: Philip Matthews In-Reply-To: <7CCEA676-DC64-4CE6-A3BF-D5F7605C2A5F@magma.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 29 Mar 2009 17:39:41 -0700 References: <7CCEA676-DC64-4CE6-A3BF-D5F7605C2A5F@magma.ca> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7410; t=1238373582; x=1239237582; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[BEHAVE]=20Plan=20for=20IPv4/IPv6=20tra nslation=20documents |Sender:=20; bh=xHTrQbd+LK1N3tCHCwmByAhv1hRnMpF0IAGrzlcnIOo=; b=Yvu7TzeQ5MYlfMt3OwEQA8BV8ub2Ltnd+wS9+qqk5ZIXLDA9N/H7hDv1H6 gsEaQoBR08/NPQXGL3Tiy4hnSQX+idxaUMNFW/6crkAKZBX5tOuGNEc98A/e +o5NbePTRW; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Behave WG , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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, 30 Mar 2009 00:38:46 -0000 Speaking strictly for myself, I object. I refer you to the code I showed you Friday morning, which I have posted at ftp://ftpeng.cisco.com/fred/behave/translate.c.numbered. This is a prototype implementation, more pseudo-code than true C, but could be turned into an implementation with a little thought. What you are proposing is five documents to describe the conditional on lines 286-293 (a simple if-then-else with one function call and two procedure calls) and the similar conditional lines 317-330, with their supporting code on lines 201-265. What you are proposing is five internet drafts to describe a single very wee bit of code. As I told you verbally, here is what has happened with SIIT and NAT-PT at Cisco and what I expect to happen again given this working groups predilection for making things more complex than they need to be. With SIIT and NAT-PT, which put the stateless and stateful modes in separate RFCs, one was implemented (NAT-PT) and one was not (SIIT) except in the sense that NAT-PT refers to it. The fact that they were in separate documents was interpreted as "this is a choice" as opposed to "these are different parts of one algorithm". That is sheer idiocy, and is exactly what I expect to se happen if you force the galloping complexity you propose here on me. The specification is already five documents (framework, translation, stateful translation database, DNS ALG, and FTP ALG) and as of Tuesday is slated to become six documents, splitting the prefix out of the framework document into a document that you are asking me to not refer to but which was internal to SIIT and was referred to in several places. I would REALLY like to keep this implementable. I don't see value in breaking two C conditional statements into five documents in search of a science fair project trying to understand them. I would like to see this as commercial product implementable from the RFCs, which means that the RFCs have to refer to each other, and entire algorithms have to be written in single documents. I have the same view regarding the magic prefix. Operational folks, including but not limited to my co-authors and members of the IAB, have told the working group that using a magic prefix is theoretically possible but for practical reasons not what operators do. I have said as much in two working group meetings. The result as pushed by the computer scientists in the room is that we will implement a magic prefix even though the operators won't use it - and we will recommend that as the default. Another science fair project. I would really prefer to have the recommendations for operating the facility in line with the recommendations of the operational folks that have deployed it. On Mar 29, 2009, at 11:18 AM, Philip Matthews wrote: > I would like to propose a variation on Fred's proposal. > > Specifically, I would like the "IP/ICMP Translation" document (which > I will call "SIITbis") to NOT refer to the other documents, but to > stand on its own. The current SIIT document has proven very useful > in a variety of contexts, and I would like to keep that generality > in the updated version. (For example, draft-ietf-behave-turn-v6 > currently refers to SIIT, but is somewhat unrelated to the documents > below.) This means that SIITbis would have normative dependencies > only on existing RFCs, and thus not get delayed by other documents. > > For that reason, I would like to break out the Stateless translation > stuff into a separate document (to be perhaps based on draft-baker- > behave-ivi). > > The following diagram may explain this better: > > +---------------+ +------------------+ > | Stateful | | Stateless | > | nat64 | | ivi | > +---------------+ +------------------+ > | \ / | > | --------\ /....... | > v ....../ \--------- | > +---------------v----+ +---v----v---------+ > | SIITbis | | Prefix | > | | | | > +--------------------+ +------------------+ > > (Arrows are difficult to draw in ASCII art, but this shows the > Stateful and Stateless translation documents as having normative > dependencies on the SIITbis and Prefix documents, but no reverse > pointers. Furthermore, draft-ietf-behave-turn-v6 may have a > normative dependency on SIITbis, but not on the other documents). > > IN PRACTICE, this means that SIITbis should do the following: > * Have no normative dependencies on any document not currently > published as an RFC; > * Say that "this is not a complete specification, and any document > using this specification must provide certain information which is > deliberately left unspecified"; > * Whenever it talks about address or port or ICMP identifier field > translation, simply state "the details of how this field is > translated is left to the document using this specification". > > Then the Stateful and Stateless translation documents will fill in > the blanks left in SIITbis. > > Comments? > > - Philip > > > On Wed, 25-Mar-09, at 12:05 , Fred Baker wrote: > >> Referring to the October discussion and the chair's slides >> yesterday, and further to private email among the framework >> authors, the chairs, and Magnus yesterday and today, I want to >> capture what I understand to be the documentation plan. If I have >> it wrong, I would like to know that now; if I have it right I am >> already in process and want confirmation of the fact. >> >> One thing discussed privately is that the reference from the >> translation document to the prefix is normative, which means that >> the document referred to should be standards track. You asked me to >> pull the prefix into a separate document. >> >> So I understand that we have six documents called for at this >> point, with possible future ALG documents, for which I am >> suggesting appropriate monikers: >> >> IPv4/IPv6 Translation Framework >> Informational, based on draft-baker-behave-v4v6-framework-02.txt >> draft-ietf-behave-v4v6-framework-00.txt >> IPv4/IPv6 Translation Prefix recommendation >> Standards track, based on draft-baker-behave-v4v6-framework-02.txt >> draft-ietf-behave-v4v6-prefix-00.txt >> IP/ICMP Translation >> Standards track, based on draft-baker-behave-v4v6- >> translation-02.txt >> draft-ietf-behave-v4v6-translation-00.txt >> IPv4/IPv6 Stateful Translation Database Maintenance >> Standards track, based on draft-bagnulo-behave-nat64-03.txt >> draft-ietf-behave-v4v6-database-00.txt >> IPv4/IPv6 DNS Translation Database Algorithm and Gateway >> Standards track, based on draft-bagnulo-behave-dns64-02.txt >> draft-ietf-behave-v4v6-dns-00.txt >> IPv4/IPv6 FTP Application Layer Gateway >> Standards Track, to be determined >> >> Am I correct? >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > From fred@cisco.com Sun Mar 29 17:53: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 60B843A6B31 for ; Sun, 29 Mar 2009 17:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.427 X-Spam-Level: X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9wM9mUBID8c for ; Sun, 29 Mar 2009 17:53:25 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 03F623A6931 for ; Sun, 29 Mar 2009 17:53:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,443,1233532800"; d="scan'208";a="163432698" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 30 Mar 2009 00:54:22 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2U0sMVR032392; Sun, 29 Mar 2009 17:54:22 -0700 Received: from [10.242.56.95] (sjc-vpn2-571.cisco.com [10.21.114.59]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2U0sLAu008220; Mon, 30 Mar 2009 00:54:22 GMT Message-Id: From: Fred Baker To: Philip Matthews In-Reply-To: <07600313-D7B8-4E82-94D5-9306C9F3033D@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 29 Mar 2009 17:54:21 -0700 References: <7CCEA676-DC64-4CE6-A3BF-D5F7605C2A5F@magma.ca> <07600313-D7B8-4E82-94D5-9306C9F3033D@cisco.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7922; t=1238374462; x=1239238462; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[BEHAVE]=20Plan=20for=20IPv4/IPv6=20tra nslation=20documents |Sender:=20; bh=jsfvsNMoLVNuRxVe12oTQhQjfoHY+ucyfT1KS9pFTE8=; b=lxKI0R1sfsSKbEB3jNXpcvr4aWRwDAp7evpH/jkYprs6aF3uZqNBp35DHB in6FUOQd2SYt9p+JQjF4UOk5N98QPxfeZVKSt+AyaN1EVx53L1iCrVb6aGnq qhkbyw9LkqBr0lmKZFFRXz7BooRni2D4w9VVm6MJgzcCnX1x7m2S4=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Behave WG , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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, 30 Mar 2009 00:53:26 -0000 Correcting one statement, I notice that in the latest IOS release Cisco has implemented SIIT stand-alone, as in without NAT-PT. On Mar 29, 2009, at 5:39 PM, Fred Baker wrote: > Speaking strictly for myself, I object. > > I refer you to the code I showed you Friday morning, which I have > posted at ftp://ftpeng.cisco.com/fred/behave/translate.c.numbered. > This is a prototype implementation, more pseudo-code than true C, > but could be turned into an implementation with a little thought. > > What you are proposing is five documents to describe the conditional > on lines 286-293 (a simple if-then-else with one function call and > two procedure calls) and the similar conditional lines 317-330, with > their supporting code on lines 201-265. What you are proposing is > five internet drafts to describe a single very wee bit of code. > > As I told you verbally, here is what has happened with SIIT and NAT- > PT at Cisco and what I expect to happen again given this working > groups predilection for making things more complex than they need to > be. With SIIT and NAT-PT, which put the stateless and stateful modes > in separate RFCs, one was implemented (NAT-PT) and one was not > (SIIT) except in the sense that NAT-PT refers to it. The fact that > they were in separate documents was interpreted as "this is a > choice" as opposed to "these are different parts of one algorithm". > > That is sheer idiocy, and is exactly what I expect to se happen if > you force the galloping complexity you propose here on me. The > specification is already five documents (framework, translation, > stateful translation database, DNS ALG, and FTP ALG) and as of > Tuesday is slated to become six documents, splitting the prefix out > of the framework document into a document that you are asking me to > not refer to but which was internal to SIIT and was referred to in > several places. > > I would REALLY like to keep this implementable. I don't see value in > breaking two C conditional statements into five documents in search > of a science fair project trying to understand them. I would like to > see this as commercial product implementable from the RFCs, which > means that the RFCs have to refer to each other, and entire > algorithms have to be written in single documents. > > I have the same view regarding the magic prefix. Operational folks, > including but not limited to my co-authors and members of the IAB, > have told the working group that using a magic prefix is > theoretically possible but for practical reasons not what operators > do. I have said as much in two working group meetings. The result as > pushed by the computer scientists in the room is that we will > implement a magic prefix even though the operators won't use it - > and we will recommend that as the default. Another science fair > project. I would really prefer to have the recommendations for > operating the facility in line with the recommendations of the > operational folks that have deployed it. > > On Mar 29, 2009, at 11:18 AM, Philip Matthews wrote: > >> I would like to propose a variation on Fred's proposal. >> >> Specifically, I would like the "IP/ICMP Translation" document >> (which I will call "SIITbis") to NOT refer to the other documents, >> but to stand on its own. The current SIIT document has proven very >> useful in a variety of contexts, and I would like to keep that >> generality in the updated version. (For example, draft-ietf-behave- >> turn-v6 currently refers to SIIT, but is somewhat unrelated to the >> documents below.) This means that SIITbis would have normative >> dependencies only on existing RFCs, and thus not get delayed by >> other documents. >> >> For that reason, I would like to break out the Stateless >> translation stuff into a separate document (to be perhaps based on >> draft-baker-behave-ivi). >> >> The following diagram may explain this better: >> >> +---------------+ +------------------+ >> | Stateful | | Stateless | >> | nat64 | | ivi | >> +---------------+ +------------------+ >> | \ / | >> | --------\ /....... | >> v ....../ \--------- | >> +---------------v----+ +---v----v---------+ >> | SIITbis | | Prefix | >> | | | | >> +--------------------+ +------------------+ >> >> (Arrows are difficult to draw in ASCII art, but this shows the >> Stateful and Stateless translation documents as having normative >> dependencies on the SIITbis and Prefix documents, but no reverse >> pointers. Furthermore, draft-ietf-behave-turn-v6 may have a >> normative dependency on SIITbis, but not on the other documents). >> >> IN PRACTICE, this means that SIITbis should do the following: >> * Have no normative dependencies on any document not currently >> published as an RFC; >> * Say that "this is not a complete specification, and any document >> using this specification must provide certain information which is >> deliberately left unspecified"; >> * Whenever it talks about address or port or ICMP identifier field >> translation, simply state "the details of how this field is >> translated is left to the document using this specification". >> >> Then the Stateful and Stateless translation documents will fill in >> the blanks left in SIITbis. >> >> Comments? >> >> - Philip >> >> >> On Wed, 25-Mar-09, at 12:05 , Fred Baker wrote: >> >>> Referring to the October discussion and the chair's slides >>> yesterday, and further to private email among the framework >>> authors, the chairs, and Magnus yesterday and today, I want to >>> capture what I understand to be the documentation plan. If I have >>> it wrong, I would like to know that now; if I have it right I am >>> already in process and want confirmation of the fact. >>> >>> One thing discussed privately is that the reference from the >>> translation document to the prefix is normative, which means that >>> the document referred to should be standards track. You asked me >>> to pull the prefix into a separate document. >>> >>> So I understand that we have six documents called for at this >>> point, with possible future ALG documents, for which I am >>> suggesting appropriate monikers: >>> >>> IPv4/IPv6 Translation Framework >>> Informational, based on draft-baker-behave-v4v6-framework-02.txt >>> draft-ietf-behave-v4v6-framework-00.txt >>> IPv4/IPv6 Translation Prefix recommendation >>> Standards track, based on draft-baker-behave-v4v6-framework-02.txt >>> draft-ietf-behave-v4v6-prefix-00.txt >>> IP/ICMP Translation >>> Standards track, based on draft-baker-behave-v4v6- >>> translation-02.txt >>> draft-ietf-behave-v4v6-translation-00.txt >>> IPv4/IPv6 Stateful Translation Database Maintenance >>> Standards track, based on draft-bagnulo-behave-nat64-03.txt >>> draft-ietf-behave-v4v6-database-00.txt >>> IPv4/IPv6 DNS Translation Database Algorithm and Gateway >>> Standards track, based on draft-bagnulo-behave-dns64-02.txt >>> draft-ietf-behave-v4v6-dns-00.txt >>> IPv4/IPv6 FTP Application Layer Gateway >>> Standards Track, to be determined >>> >>> Am I correct? >>> >>> _______________________________________________ >>> 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 moore@network-heretics.com Sun Mar 29 18:39: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 EC2A03A6C2B for ; Sun, 29 Mar 2009 18:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qdDs2cUUswy for ; Sun, 29 Mar 2009 18:39:33 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 2FE723A68CE for ; Sun, 29 Mar 2009 18:39:33 -0700 (PDT) Received: from lust.indecency.org (68-31-145-121.pools.spcsdns.net [68.31.145.121]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMD26109 (AUTH admin@network-heretics.com); Sun, 29 Mar 2009 18:40:04 -0700 (PDT) Message-ID: <49D022F2.20907@network-heretics.com> Date: Sun, 29 Mar 2009 20:40:02 -0500 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Fred Baker References: <7CCEA676-DC64-4CE6-A3BF-D5F7605C2A5F@magma.ca> <07600313-D7B8-4E82-94D5-9306C9F3033D@cisco.com> In-Reply-To: <07600313-D7B8-4E82-94D5-9306C9F3033D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Behave WG , Philip Matthews , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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, 30 Mar 2009 01:39:34 -0000 Fred Baker wrote: > I have the same view regarding the magic prefix. Operational folks, > including but not limited to my co-authors and members of the IAB, have > told the working group that using a magic prefix is theoretically > possible but for practical reasons not what operators do. I have said as > much in two working group meetings. The result as pushed by the computer > scientists in the room is that we will implement a magic prefix even > though the operators won't use it - and we will recommend that as the > default. I really didn't like the way the question was phrased in SF, but it's hard to phrase such questions well in a WG meeting. Personally, the only sense that I think the magic prefix should be a "default" is in the sense of "last resort". As in, you SHOULD use an LIR prefix, and all of the relevant protocols and software need to accommodate the ability to configure that LIR prefix. But if for some reason you actually think you want to use a magic prefix, please use this one allocated by IANA for that purpose, rather than (say) pulling one out of thin air, or using a prefix allocated for a different purpose. Keith From fred@cisco.com Sun Mar 29 20:16: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 DE33E3A6C8E for ; Sun, 29 Mar 2009 20:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.43 X-Spam-Level: X-Spam-Status: No, score=-106.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REhhDezpZFrv for ; Sun, 29 Mar 2009 20:16:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F05DF3A682F for ; Sun, 29 Mar 2009 20:16:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,443,1233532800"; d="scan'208";a="276393678" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2009 03:17:32 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2U3HWWV027396; Sun, 29 Mar 2009 20:17:32 -0700 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2U3HWjc009170; Mon, 30 Mar 2009 03:17:32 GMT Message-Id: From: Fred Baker To: Keith Moore In-Reply-To: <49D022F2.20907@network-heretics.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 29 Mar 2009 20:17:29 -0700 References: <7CCEA676-DC64-4CE6-A3BF-D5F7605C2A5F@magma.ca> <07600313-D7B8-4E82-94D5-9306C9F3033D@cisco.com> <49D022F2.20907@network-heretics.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=944; t=1238383052; x=1239247052; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[BEHAVE]=20Plan=20for=20IPv4/IPv6=20tra nslation=20documents |Sender:=20; bh=T7cmKzBu2/dbhRctOArUdNREBlETXDydt00wP7laYGM=; b=fw+eBvfEAYpaLpr6uLTrMN8XZlBYNL8Wo92L+iJhY5oSqDUNpza/oxhdF2 tMLzkcsWKI5JGlq6F+NasZP5pAJgjU4Gym8WcmP8DjCq3XcP0A1XCRRJ8JLN xHWQlowJKI; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Behave WG , Philip Matthews , Behave Chairs Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation 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, 30 Mar 2009 03:16:36 -0000 On Mar 29, 2009, at 6:40 PM, Keith Moore wrote: > Personally, the only sense that I think the magic prefix should be a > "default" is in the sense of "last resort". As in, you SHOULD use > an LIR prefix, and all of the relevant protocols and software need > to accommodate the ability to configure that LIR prefix. But if for > some reason you actually think you want to use a magic prefix, > please use this one allocated by IANA for that purpose, rather than > (say) pulling one out of thin air, or using a prefix allocated for a > different purpose. If the working group would like me to word it that way, I'm OK with that. the way the question was worded in the working group was exactly the opposite, and the options given were a) only use an LIR prefix, and b) request a magic prefix and by default use it There was no third option, "request a magic prefix and give guidance on its use" From David.Miles@alcatel-lucent.com.au Mon Mar 30 21:19: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 41D6A3A6AE0; Mon, 30 Mar 2009 21:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 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 9hV0HpjGutLT; Mon, 30 Mar 2009 21:19:32 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 342E13A6966; Mon, 30 Mar 2009 21:19:32 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n2V4KRDq026349; Mon, 30 Mar 2009 23:20:27 -0500 (CDT) Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n2V4KQRr010594; Mon, 30 Mar 2009 23:20:27 -0500 (CDT) Received: from sgsinsbhs02.ad4.ad.alcatel.com (sgsinsbhs02.ap.lucent.com [135.254.109.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id n2V4JDve020692; Tue, 31 Mar 2009 12:19:13 +0800 Received: from SGSINSMBS02.ad4.ad.alcatel.com ([135.254.109.30]) by sgsinsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 12:20:25 +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, 31 Mar 2009 12:20:21 +0800 Message-ID: <986DCE2E44129444B6435ABE8C9E424D02FDFA42@SGSINSMBS02.ad4.ad.alcatel.com> In-Reply-To: <021601c9b098$801cabd0$c2158182@NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] [shara] Follow up on Layer2-Aware NAT(draft-miles-behave-l2nat-00) Thread-Index: AcmgdlhcsqF9XOaRSFmUv5LfTG7d5QAAEU/wA2dPQ2AASTlpgABXncyQAEgXtoA= References: <986DCE2E44129444B6435ABE8C9E424D02D5CE0A@SGSINSMBS02.ad4.ad.alcatel.com> <986DCE2E44129444B6435ABE8C9E424D02F7E95D@SGSINSMBS02.ad4.ad.alcatel.com> <021601c9b098$801cabd0$c2158182@NOE.Nokia.com> From: "MILES DAVID" To: "Gabor Bajko" , , , X-OriginalArrivalTime: 31 Mar 2009 04:20:25.0145 (UTC) FILETIME=[03BAEA90:01C9B1B8] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130 Subject: Re: [BEHAVE] [shara] Follow up on Layer2-Aware NAT(draft-miles-behave-l2nat-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, 31 Mar 2009 04:19:33 -0000 Hi Gabor, I understand that the last slide was far too generalized.=20 All transition solutions will involve a degree of IPv4 if they involve a v4 client - in L2-Aware NAT there is a component of IPv4 NAPT but this does not preclude the approach from using IPv4-in-IPv6 tunneling solutions. You'll get no objection from me that IPv4 is a dead-end - what we are trying to do is provide -minimal- support for IPv4 during the transition period to IPv6. Cheers, -David -----Original Message----- From: Gabor Bajko [mailto:gaborbajko@gmail.com]=20 Sent: Monday, March 30, 2009 5:02 AM To: MILES DAVID; pierre.levis@orange-ftgroup.com; behave@ietf.org; shara@ietf.org Subject: RE: [BEHAVE] [shara] Follow up on Layer2-Aware NAT(draft-miles-behave-l2nat-00) There were a number of inconsistencies on the comparison slide (eg, that IPv4 traffic is subject to NAPT in case of A+P, etc).=20 It has to be clearly stated that what this solution offers is a technological dead-end, as there is no evolution path away from IPv4 in it.=20 - gabor >-----Original Message----- >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf >Of MILES DAVID >Sent: Friday, March 27, 2009 5:27 PM >To: pierre.levis@orange-ftgroup.com; behave@ietf.org; shara@ietf.org >Subject: Re: [BEHAVE] [shara] Follow up on Layer2-Aware NAT(draft-miles- >behave-l2nat-00) > >Pierre, > >Thanks for the support. The presentation of draft-nishitani-cgn-01 >outlined a good way forward - here the Network Model was separated from >the core NAT Function. I think a L2-Aware NAT best belongs in a core >document like this. >In this way L2-Aware NAT could make up an optional component of the core >NAT Function (in the way it describes a Virtual NAT [tables] facility). >On top of this a variety of network models could be created and >documented - these could even come from other working groups (such as >Softwires).I believe a core NAT function (regardless of whether we >describe IPv4 or IPv6) fits well in BEHAVE. > >Applying the mechanisms in L2-Aware NAT to PRR makes a lot of sense as >well - I'm wondering if port-range solutions could be described (perhaps >poorly) as similar to a NAPT mapping function (outside-ip/port to >inside-ip/port) however in the case of PRR, the pairs are the >same/common - in effect a address/port translation does not occur. What >do you think of attempting to describe the PRR function like this? > >If agreeable I would like to invite the authors of PRR/A+P and CGN >drafts to work within the bounds of a new draft that describes a core >NAT function (without drawing reference to size or scale) - introducing >elements of core NAT function (CGN/LSN) virtual NAPT tables (L2-Aware >NAT), and mappings tables where translation is not applied (PRR). > >Best Regards, > >-David > >-----Original Message----- >From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf >Of pierre.levis@orange-ftgroup.com >Sent: Thursday, March 26, 2009 6:17 AM >To: behave@ietf.org; shara@ietf.org >Subject: [shara] Follow up on Layer2-Aware NAT >(draft-miles-behave-l2nat-00) > >The comment I had on the mike during behave session 2: > >This kind of work is very valuable, it is worth not only for CGN but >also for Port Ranges solutions and for all IPv4 shortage solutions. >As we presented it in the shara BoF all solutions basically: >1) Put a dedicated function in an ISP Box (CGN, PRR, whatever) >2) Use some sort of transport mechanism (tunneling, layer 2, whatever) >between customers and ISPBox, >3) Are confronted with the same issues: how to force a route from >customers to ISPBox, how to route back from ISPBox to relevant customer, >how to identify the customer. > >This would advocate for seeing all work related to IPv4 shared addresses >host in the same place, under the same ombrella. > > >Regards > >Pierre >_______________________________________________ >shara mailing list >shara@ietf.org >https://www.ietf.org/mailman/listinfo/shara >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From pete.mccann@motorola.com Mon Mar 30 13: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 3963328C0E7; Mon, 30 Mar 2009 13:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 A+201mEpQcgW; Mon, 30 Mar 2009 13:01:11 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id E896B3A6846; Mon, 30 Mar 2009 13:01:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-2.tower-55.messagelabs.com!1238443325!38986097!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10383 invoked from network); 30 Mar 2009 20:02:05 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Mar 2009 20:02:05 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n2UK25jZ027803; Mon, 30 Mar 2009 13:02:05 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id n2UK244j002823; Mon, 30 Mar 2009 15:02:04 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id n2UK24C8002818; Mon, 30 Mar 2009 15:02:04 -0500 (CDT) 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: Mon, 30 Mar 2009 16:02:03 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART Review of draft-ietf-behave-nat-behavior-discovery-06 Thread-Index: AcmxcmTy1a868Rv5QZK9Ln+04WTpow== From: "McCann Peter-A001034" To: , X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 31 Mar 2009 09:37:58 -0700 Cc: behave@ietf.org, behave-ads@tools.ietf.org, behave-chairs@tools.ietf.org Subject: [BEHAVE] Gen-ART Review of draft-ietf-behave-nat-behavior-discovery-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2009 20:01:12 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-behave-nat-behavior-discovery-06 Reviewer: Pete McCann Review Date: 30 March 2009 IETF LC End Date: 31 March 2009 IESG Telechat date: unknown=20 Summary: Ready for publication as an Experimental RFC. Major issues: NONE Minor issues: The Abstract incorrectly defines STUN to be:=20 Simple Traversal Underneath Network Address Translators Later in the draft, STUN is correctly expanded to: Session Traversal Utilities for NAT End of Section 2.2: apocryphal evidence Did you mean "anecdotal evidence"? Section 6.1 states: If the Request contained a PADDING attribute, PADDING MUST be included in the Binding Response. The server SHOULD use a length of PADDING equal to the MTU on the outgoing interface. Section 7.7 states: PADDING MUST NOT be longer than the length that brings the total IP datagram size to 64K and SHOULD be an even multiple of four bytes. Because STUN messages with PADDING are intended to test the behavior of UDP fragments, they are an exception to the usual rule that STUN messages be less than the MTU of the path. These two statements are not incompatible; however, I wonder if you=20 wanted to mandate literally "length of PADDING equal to the MTU". Together with other fields, this would bring the total length up to something above the MTU, so fragmentation would happen (as desired). It might help the reader to repeat the SHOULD from 6.1 in the text in 7.7. Nits/editorial comments:=20 Section 8: This draft defines new STUN response code. SHOULD BE: This draft defines two new STUN response codes. From dwing@cisco.com Tue Mar 31 20:07: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 991E13A6822 for ; Tue, 31 Mar 2009 20:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.692 X-Spam-Level: X-Spam-Status: No, score=-6.692 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 sRe0hhQ8T0-v for ; Tue, 31 Mar 2009 20:07:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6EFA63A659C for ; Tue, 31 Mar 2009 20:07:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,305,1235952000"; d="scan'208";a="277821849" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2009 03:08:49 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3138nR4010307; Tue, 31 Mar 2009 20:08:49 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n3138nr1004313; Wed, 1 Apr 2009 03:08:49 GMT From: "Dan Wing" To: Date: Tue, 31 Mar 2009 20:08:52 -0700 Message-ID: <022801c9b277$2f5c99e0$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: AcmyIUW2ikbZIw5YTEmzRV4tWpL7fQAVbzaw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6106; t=1238555329; x=1239419329; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20FW=3A=20[BEHAVE]=20Last=20Call=3A=20draft-ietf- behave-nat-behavior-discovery=20(NATBehavior=20Discovery=20U sing=20STUN)=20to=20Experimental=20RFC |Sender:=20; bh=zFo2piM1SnIGQmHGpd2J5i6u2rIRaBy8qC+giNHZH+s=; b=EuYpnxUJ0i/IS+zWCJTvrCpp1QnIRA19lM8w5N3E169Y/ICYAo9xgX2qUn eRMDQy6kBJ804j/O3yQ4tLF7vkuLwHtc7wbt20296zcHcwAxKNQ7r/RzrcvY EYrvVwxnW5; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: draft-ietf-behave-nat-behavior-discovery@tools.ietf.org Subject: [BEHAVE] FW: Last Call: draft-ietf-behave-nat-behavior-discovery (NATBehavior 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: Wed, 01 Apr 2009 03:07:50 -0000 Forwarded for those that don't follow the main IETF list. Please reply to the list if you agree or disagree with the points raised by Cullen. Thanks. -d -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, March 31, 2009 9:53 AM To: IETF Discussion; IESG IESG Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-nat-behavior-discovery (NATBehavior Discovery Using STUN) to Experimental RFC I was somewhat shocked to see the draft in IETF Last Call. The last time this draft was discussed at the microphone in Behave, many people were very concerned that it id not possible to correctly characterize a NAT without using more than one address behind the NAT. The tests done on on NATs by the researches at MIT did that, so did the the stuff from Cornell, as did draft-jennings-behave-test-results. The reason why this was needed is largely the reason why the IETF invented ICE. Initially folks thought that STUN alone would be enough to do NAT traversal. This turned out not to be true, STUN deprecated those parts and ICE was started. This draft fails to describe the types of test that have actually been found to work and just reinstates the stuff that was deployed and failed and then deprecated out of STUN. Now this draft pays some lip service to the fact that it basically won't work. You can read section 1 and get the full idea. The first and 2'nd par basically say this won't work. Then para 3 proposes this is experiment to find out something we already know the answer to. When this work was chartered, it was about making a way to characterize NATs and describe them in a controlled lab like environment. It was not about resurrecting exactly the part of STUN that had been tried, failed , and deprecated. Specific problems with the draft.... 2.2 - this just won't work. The test described in this draft will not find out if the node is behind an endpoint independent nat. I have specific nats where it won't work. I have explained to the authors why it won't work. The answer I get back is "it might work some of the time". It true it might work some of the time but we all agree there are many NATs for which it will not work. Other section that don't work are 3.1, 3.2, 3.3, 3.4, 3.5, 3.5 - uh all of them actually. I'm glad to provide details on why they don't work but I have in the past and we not really debating if they work or not. The authors believe there is sufficient text at the beginning of the draft in section 1 that it is OK that these fail in many cases and don't need to be mentioned again. We not debating these work some of the but not all the time - everyone agrees on that. Section 4.1 - The results in here will be just wrong for ports different than the one the test was run on. The response to this was to add "use same port when possible". That's not going to exactly cause applications to work. Section 4.2 - Can't really separate the topic from if UDP is blocked from if the STUN server is down. Section 4.4 - this fails if the port was recently used for similar tests from same stun server. There no way to know this as an application. This type of test can work in lab condition where all traffic on NAT is controlled but it operational networks it will fail. It is possible to do timing testing using just the change ip flag. The REPSONSE-TARGET stuff is not needed and open up the possibility to have a STUN server send packets to places that it should not which causes IDS system to black list all traffic from the STUN server thus making it unusable for other clients. The ability to tell the STUN server to send packets to arbitrary locations would be fine for a system in a lab used to characterize a NAT but is not a good idea for internet deployed STUN servers. The bulk of these issues were sent Aug 28 to behave list during the 2nd WGLC. I requested agenda time during IETF 74 to discuss these issues but it was denied. In summary -The approaches described in this draft are known to fail with many NATs. I don't see any evidence of the WG actually having read this draft much less have consensus on the approach in it. I think the WG should spend meeting time to discuss the topic and decide what to do. The key topic in my mind is we are defining a document that allows us to characterize a NAT in a lab or if we are trying to make something that works in field and can be used to aid NAT traversal in applications. Cullen On Mar 10, 2009, at 8:44 AM, The IESG wrote: > The IESG has received a request from the Behavior Engineering for > Hindrance Avoidance WG (behave) to consider the following document: > > - 'NAT Behavior Discovery Using STUN ' > as an Experimental > RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2009-03-31. 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-nat-behavior-discovery-0 6.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15728& rfc_flag=0 > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/919/ > https://datatracker.ietf.org/ipr/945/ > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf