From bingxuere@gmail.com Tue Nov 1 01:41:55 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7DC21F8F9B for ; Tue, 1 Nov 2011 01:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1smNbGpjucK3 for ; Tue, 1 Nov 2011 01:41:54 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED0621F8F9A for ; Tue, 1 Nov 2011 01:41:54 -0700 (PDT) Received: by iaeo4 with SMTP id o4so437864iae.31 for ; Tue, 01 Nov 2011 01:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=omnUMOe2B8l7FPWtJeMt4JaJiJjIwiXe4soIAK/ZVYE=; b=e3ATz2u+YH0Go/jwwNQYP9HmDFw8s/+WcrLO2XtMdUVV9MxRGm+0vXIMHUytWMXPIX MrdAd+FpLLbT2qsztRBWd1IKIbK1WuaMp9uMAREBndTn18YifUq93vvDqjoL1bLR0AVr n3rW+mN9MVHqpa7gzp0UZFf4HGNHZYxo+3tYk= Received: by 10.42.41.143 with SMTP id p15mr28243274ice.9.1320136914085; Tue, 01 Nov 2011 01:41:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.218.10 with HTTP; Tue, 1 Nov 2011 01:41:11 -0700 (PDT) In-Reply-To: References: <412F66EB-9ADF-448D-9324-582F2D0B9AFD@cisco.com> From: Qiong Date: Tue, 1 Nov 2011 16:41:11 +0800 Message-ID: To: Olivier Vautrin Content-Type: multipart/alternative; boundary=20cf301d424cd1a80b04b0a85332 Cc: "behave@ietf.org" , Dan Wing , Benson Schliesser Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 08:41:55 -0000 --20cf301d424cd1a80b04b0a85332 Content-Type: text/plain; charset=UTF-8 Hi Olivier, On Tue, Nov 1, 2011 at 1:32 PM, Olivier Vautrin wrote: > I agree. What about "SHOULD" support per-connection if logging is not > needed. "SHOULD" support bulk port allocation if Logging is needed. > > +1. I also think bulk port allocation is rather important for logging, especially for large-scale operators. Best wishes Qiong > Cheers, > Olivier > > On 10/28/11 8:21 PM, "Benson Schliesser" wrote: > > > > >On Oct 28, 2011, at 7:44 PM, Olivier Vautrin wrote: > > > >> What about the "bulk port allocation"? The draft is explaining in detail > >> the mechanism but do not give any recommendation. I think we should at > >> least have a "SHOULD" to support the bulk port allocation. It is > >>difficult > >> to believe that in the future, service providers we will still log all > >>the > >> sessions on a CGN device. > > > >I tend to agree with your conclusion. However, if we do per-connection > >allocation of ports, then there might be benefits to the CGN operator and > >users. For instance, there might be improved security and more efficient > >utilization of CGN port resources. Thus, an operator that doesn't care > >about logging might not want to use bulk port allocation. > > > >My opinion is that if we say that a CGN "SHOULD" do bulk port allocation, > >then we should also say that it "MAY" do per-connection port allocation > >(based on the rationale I just described). Thoughts on this? > > > >Cheers, > >-Benson > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --20cf301d424cd1a80b04b0a85332 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Olivier,

On Tue, Nov 1, 2011 at 1:32 = PM, Olivier Vautrin <ovautrin@juniper.net> wrote:
I agree. What about "SHOULD" support per-connection if logging is= not
needed. "SHOULD" support bulk port allocation if Logging is neede= d.

+1. I also think bulk port allocation is rather impor= tant for logging, especially for large-scale operators.

Best wishes

Qiong

=C2=A0
Cheers,
Olivier

On 10/28/11 8:21 PM, "Benson Schliesser" <bschlies@cisco.com> wrote:

>
>On Oct 28, 2011, at 7:44 PM, Olivier Vautrin wrote:
>
>> What about the "bulk port allocation"? The draft is expl= aining in detail
>> the mechanism but do not give any recommendation. I think we shoul= d at
>> least have a "SHOULD" to support the bulk port allocatio= n. It is
>>difficult
>> to believe that in the future, service providers we will still log= all
>>the
>> sessions on a CGN device.
>
>I tend to agree with your conclusion. =C2=A0However, if we do per-conne= ction
>allocation of ports, then there might be benefits to the CGN operator a= nd
>users. =C2=A0For instance, there might be improved security and more ef= ficient
>utilization of CGN port resources. =C2=A0Thus, an operator that doesn&#= 39;t care
>about logging might not want to use bulk port allocation.
>
>My opinion is that if we say that a CGN "SHOULD" do bulk port= allocation,
>then we should also say that it "MAY" do per-connection port = allocation
>(based on the rationale I just described). =C2=A0Thoughts on this?
>
>Cheers,
>-Benson
>

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

--20cf301d424cd1a80b04b0a85332-- From moore@network-heretics.com Tue Nov 1 05:05:37 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9A821F910E; Tue, 1 Nov 2011 05:05:37 -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.770, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg3HDksGjLcr; Tue, 1 Nov 2011 05:05:36 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id D047921F8C84; Tue, 1 Nov 2011 05:05:36 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 242CA20CC1; Tue, 1 Nov 2011 08:05:30 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 01 Nov 2011 08:05:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=QJpD/cqe2AqoVU846CZIyKUtP9k=; b=Uk dZBL4I3mL3frA5NZ/uFeCQ9Bv2nIKSg5OHuUZd4B2mX0KcQEIVmY2Pquy9k7+xdQ WueYKPs6FKR5dchDQZaJOxCDqUaw5LZD8cBi7hZIyDRZeHd8XOXWJr8+gGj58LDx JeTiUlq6W4G45FgBJKPIaU4H5AE/wOpSxyuGP7qmM= X-Sasl-enc: QunLAAOFjBxZ3TvGL/TWmzHDttDScq/4XPsDjY9Zbreq 1320149129 Received: from [10.59.1.8] (static-71-166-174-114.washdc.east.verizon.net [71.166.174.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 634254834EC; Tue, 1 Nov 2011 08:05:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4EAF9391.5040209@it.aoyama.ac.jp> Date: Tue, 1 Nov 2011 08:05:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1084) Cc: Ned Freed , Harald Alvestrand , "rtcweb@ietf.org" , Keith Moore , Behave WG Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 12:05:37 -0000 >> The "s" convention was a hack to distinguish "x over SSL" from "x" = for all of the URIs that existed before SSL was well-established, = because those protocols didn't (then) have a way to negotiate security = in-band. It made sense as a short term hack, >=20 > Yes. It also makes sense in current-day operation. >=20 >> but not as an architectural feature. It's not something that we = want to propagate to new URI types, neither in the form of an "s" = suffix, nor as any other syntactic convention. >=20 > In most cases probably not. But there may be cases similar to HTTP/S = where it makes sense. Each case has to be analyzed independently. agree. I just don't think it's a good idea to establish a new = _convention_. regards, Keith From duerst@it.aoyama.ac.jp Mon Oct 31 23:37:36 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E668011E808E for ; Mon, 31 Oct 2011 23:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.872 X-Spam-Level: X-Spam-Status: No, score=-98.872 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZA6BuCTXvZ0 for ; Mon, 31 Oct 2011 23:37:36 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 93AD111E80B2 for ; Mon, 31 Oct 2011 23:37:29 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pA16bDPv011422 for ; Tue, 1 Nov 2011 15:37:17 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1e1b_09b8_ef1b3efe_0453_11e1_abe7_001d096c5782; Tue, 01 Nov 2011 15:37:13 +0900 Received: from [IPv6:::1] ([133.2.210.1]:60382) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 1 Nov 2011 15:37:17 +0900 Message-ID: <4EAF9391.5040209@it.aoyama.ac.jp> Date: Tue, 01 Nov 2011 15:37:05 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Keith Moore References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> In-Reply-To: <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 01 Nov 2011 08:30:05 -0700 Cc: Ned Freed , Harald Alvestrand , "rtcweb@ietf.org" , Keith Moore , Behave WG Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 06:37:37 -0000 On 2011/11/01 0:33, Keith Moore wrote: > > On Oct 31, 2011, at 10:57 AM, Marc Petit-Huguenin wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Martin, >> >> So I understand Roy's email as saying in fact the opposite of what Harald said, >> i.e. that using an "s" suffix to signify security is a good thing. >> >> What is your opinion on defining a generic scheme suffix (i.e. "+s" or "+sec") >> that would indicate a well defined set of security properties that could apply >> to any scheme, (vs the current "s" suffix where security properties has to be >> defined scheme by scheme)? > > > There is no "well defined set of security properties that could apply to any scheme". Security properties necessarily vary depending on the way a resource is used, the threat model, and so forth. Here I agree with Keith. > Also, the idea that there should be a "secure" bit in a URI scheme, to distinguish it from the "insecure" form of a URL, doesn't make much sense. You always want to use the best security that's available. You always want the best security you're willing to pay for. > You don't want that to depend on the URI scheme. Ideally not, but in actual operation, it made a lot of sense for HTTP as Roy has explained. > The "s" convention was a hack to distinguish "x over SSL" from "x" for all of the URIs that existed before SSL was well-established, because those protocols didn't (then) have a way to negotiate security in-band. It made sense as a short term hack, Yes. It also makes sense in current-day operation. > but not as an architectural feature. It's not something that we want to propagate to new URI types, neither in the form of an "s" suffix, nor as any other syntactic convention. In most cases probably not. But there may be cases similar to HTTP/S where it makes sense. Each case has to be analyzed independently. Regards, Martin. > Keith > > From dwing@cisco.com Tue Nov 1 09:27:42 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA19521F9A56 for ; Tue, 1 Nov 2011 09:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.557 X-Spam-Level: X-Spam-Status: No, score=-105.557 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4jtindnNDyD for ; Tue, 1 Nov 2011 09:27:41 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 860E621F9A55 for ; Tue, 1 Nov 2011 09:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6153; q=dns/txt; s=iport; t=1320164854; x=1321374454; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=jBceGLBc0kHQw4uvX1kVowmVoyWDswsD8iC0lWUnsvw=; b=b1gldzqsOGzLUZYemoaTbRegrSl9oCgmJQcZ1AxPobU4nspXEb5GXN/v IwVztIFapZBSAvIuUnU7dssC9OQfW/ox6I+odEIl0m5QeEq7ff2vfc8En uNwAhHHIyo6ZcUhTE6x/clIftqBLxt4w33zGRG3mIq4E70ILRdizFqpmt c=; X-IronPort-AV: E=Sophos;i="4.69,438,1315180800"; d="scan'208";a="11675088" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 01 Nov 2011 16:27:26 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA1GRQIJ009384; Tue, 1 Nov 2011 16:27:26 GMT From: "Dan Wing" To: "'Brian E Carpenter'" , "'Prashanth Patil'" References: <4EAF0384.1050002@gmail.com> In-Reply-To: <4EAF0384.1050002@gmail.com> Date: Tue, 1 Nov 2011 09:27:26 -0700 Message-ID: <1be201cc98b3$249d7a90$6dd86fb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyYCuef+qNDnfMuTHCT8zZ0N93m6wAplMBg Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 16:27:42 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Brian E Carpenter > Sent: Monday, October 31, 2011 1:22 PM > To: Prashanth Patil > Cc: behave@ietf.org > Subject: Re: [BEHAVE] I-D Action: = draft-wing-behave-dhcpv6-reconfigure- > 00.txt >=20 > I don't get it. If a host is dual stacked it can be configured with > any DNS server, as long as it is not a DNS64. If you can have a > DNS64 directly visible, and a v4-only DNS server directly visible, > you are on a dual stack network, so you can also have a dual stack > DNS server directly visible. It is anticipated that a network will have a mix of IPv4-only, IPv6-only, and dual-stack hosts. The hosts don't know if they need a 'normal' DNS server or a DNS64, nor do we have a way to tell them the difference. This I-D attempts to provide a solution to that problem of a=20 network with a mix of hosts that need to be configured with a=20 'normal' DNS server and DNS64 server. We believe the underlying=20 idea (to "poke" a host to tell it something changed on the=20 network) appears to have other applicability beyond the DNS/DNS64 use-case, as well. -d > Regards > Brian Carpenter >=20 > On 2011-11-01 05:05, Prashanth Patil wrote: > > Hi Brian, > > The idea behind the proposal is to provision a means by which = traffic > is > > sent using IPv4 and not through the IPv6/IPv4 translator. The > advantage > > being that if NAT44 and NAT64 are deployed on the same network, it = is > > preferable to use NAT44 over NAT64 because of scale, performance and > > application incompatibility issues (e.g., FTP) [RFC6384]. > > A "normal" DNS server does not have DNS64 capability. The = IPv4-mapped > > address for this "normal" server ensures that it can be reached only > by > > IPv4=C5=A1. So if a host is IPv4-only, it will send a DNS query to = the > "normal" > > server just to get the A records. If the host is dual-stack it will > also > > send a DNS query to the "normal" server to get both A and AAAA > records. If > > the destination address is an IPv4 address, dual-stack host just > gets A > > records but not synthesized AAAA records. So this technique will > ensure that > > IPv4 is preferred over the IPv6/IPv4 translator prefix and also = gives > native > > IPv6 higher precedence than IPv4. > > If the host happens to be IPv6 only, then it cannot reach the > "normal" > > server because it has IPv4-mapped prefix as explained previously. So > IPv6 > > only host can only reach DNS64 server. So this host will send the = DNS > query > > to DNS64 to get AAAA records. Based on the destination address the > host will > > get IPv4-embedded IPv6 address or just the global IPv6 address. > > > > =C5=A1Note: From RFC 6052 > > =C2=B3When presented with the IPv4-mapped prefix, current versions = of > Windows and > > Mac OS generate IPv4 packets, but will not send IPv6 packets.=C2=B2 > > > > -Prashanth > > > > On 22/10/11 6:20 AM, Brian E Carpenter wrote: > >> I have a basic question. Why does this draft define a 'normal' > >> DNS server as one having an IPv4-mapped IPv6 address? > >> > >> That seems like a completely *abnormal* DNS server for a dual > >> stack host. A dual stack host should normally have a DNS server > >> with a regular IPv6 address that will return both A and AAAA > >> records if they exist. Normally the server will be dual stacked > >> anyway, and will return exactly the same response whether the > >> query arrives via v4 or v6. > >> > >> A DNS server which only has an IPv4 address will also return > >> A and AAAA records if they exist, so there is absolutely no > >> difference as far as the dual stack host is concerned anyway. > >> So what is the point in using the IPv4-mapped address? > >> > >> Regards > >> Brian > >> > >> On 2011-10-18 11:17, internet-drafts@ietf.org wrote: > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> > >>> Title : DHCPv6 Dynamic Re-Configuration > >>> Author(s) : Dan Wing > >>> Tirumaleswar Reddy > >>> Prashanth Patil > >>> Filename : draft-wing-behave-dhcpv6-reconfigure-00.txt > >>> Pages : 10 > >>> Date : 2011-10-17 > >>> > >>> Some networks are expected to support IPv4-only, dual-stack, > and > >>> IPV6-only hosts at the same time. This makes prioritizing the > DNS > >>> servers for hosts tricky due to a heterogeneous mix of = protocol > >>> stacks causing optimal behavior to occur only when the host > stack re- > >>> initializes. The networks infrastructure is usually well > equipped to > >>> be aware of single/dual-stack nature of hosts. This > specification > >>> extends DHCPv6 so that the DHCPv6 Relay Agent can dynamically > >>> influence the priority of DNS servers provided to the host, so > that > >>> the host can use the optimal DNS server for resolution. > >>> > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- > reconfigure-00.t > >>> xt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> This Internet-Draft can be retrieved at: > >>> ftp://ftp.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- > reconfigure-00.tx > >>> t > >>> _______________________________________________ > >>> 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 > >>> > >> _______________________________________________ > >> 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 roberta.maglione@telecomitalia.it Tue Nov 1 09:59:47 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CA71F0CB6 for ; Tue, 1 Nov 2011 09:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpxqV+vC2mvJ for ; Tue, 1 Nov 2011 09:59:46 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 567411F0CB9 for ; Tue, 1 Nov 2011 09:59:39 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 1 Nov 2011 17:47:34 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Tue, 1 Nov 2011 17:47:34 +0100 From: Maglione Roberta To: Olivier Vautrin , Benson Schliesser Date: Tue, 1 Nov 2011 17:45:28 +0100 Thread-Topic: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) Thread-Index: AcyYV7P69e96dZr5S4+PuzLGA6AkBgAXfWZF Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C82@GRFMBX704BA020.griffon.local> References: <412F66EB-9ADF-448D-9324-582F2D0B9AFD@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" , Dan Wing Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 16:59:47 -0000 Hello, I support Olivier=92s proposal, the "bulk port allocation" is an import= ant feature for logging reduction. Roberta ________________________________________ From: behave-bounces@ietf.org [behave-bounces@ietf.org] On Behalf Of Olivie= r Vautrin [ovautrin@juniper.net] Sent: Tuesday, November 01, 2011 6:32 AM To: Benson Schliesser Cc: behave@ietf.org; Dan Wing Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requ= irements) I agree. What about "SHOULD" support per-connection if logging is not needed. "SHOULD" support bulk port allocation if Logging is needed. Cheers, Olivier On 10/28/11 8:21 PM, "Benson Schliesser" wrote: > >On Oct 28, 2011, at 7:44 PM, Olivier Vautrin wrote: > >> What about the "bulk port allocation"? The draft is explaining in detail >> the mechanism but do not give any recommendation. I think we should at >> least have a "SHOULD" to support the bulk port allocation. It is >>difficult >> to believe that in the future, service providers we will still log all >>the >> sessions on a CGN device. > >I tend to agree with your conclusion. However, if we do per-connection >allocation of ports, then there might be benefits to the CGN operator and >users. For instance, there might be improved security and more efficient >utilization of CGN port resources. Thus, an operator that doesn't care >about logging might not want to use bulk port allocation. > >My opinion is that if we say that a CGN "SHOULD" do bulk port allocation, >then we should also say that it "MAY" do per-connection port allocation >(based on the rationale I just described). Thoughts on this? > >Cheers, >-Benson > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From petithug@acm.org Tue Nov 1 13:50:45 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9314A11E81EE; Tue, 1 Nov 2011 13:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5Xb9RXNGt8X; Tue, 1 Nov 2011 13:50:45 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 75B2911E80B0; Tue, 1 Nov 2011 13:50:34 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 95516204AD; Tue, 1 Nov 2011 20:41:39 +0000 (UTC) Message-ID: <4EB05B90.10808@acm.org> Date: Tue, 01 Nov 2011 13:50:24 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Harald Alvestrand References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> In-Reply-To: <4EB05A23.3060101@alvestrand.no> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Ned Freed , Keith Moore , "rtcweb@ietf.org" , Keith Moore , =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Behave WG Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 20:50:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2011 01:44 PM, Harald Alvestrand wrote: > Top-posting a general principle, detailed comment at the bottom.... > > For all URI schemes, I think the URI needs to contain all the information you > need in order to make contact with the service; you can't negotiate until you've > made contact. > (the process may involve things like "resolve through a resolution mechanism > like DNS" or "get authorization tokens from somewhere else"). > > In the case of TURN, you need to distinguish between TCP, UDP and TLS, and you > need to make that determination before you send the first packet. That means the > distinguishing information between those three things belongs in the URL; I > don't think the scheme is a good place to encode it. > > On 10/31/2011 11:37 PM, "Martin J. Dürst" wrote: >> >> >> On 2011/11/01 0:33, Keith Moore wrote: >>> >>> On Oct 31, 2011, at 10:57 AM, Marc Petit-Huguenin wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Hi Martin, >>>> >>>> So I understand Roy's email as saying in fact the opposite of what Harald said, >>>> i.e. that using an "s" suffix to signify security is a good thing. >>>> >>>> What is your opinion on defining a generic scheme suffix (i.e. "+s" or "+sec") >>>> that would indicate a well defined set of security properties that could apply >>>> to any scheme, (vs the current "s" suffix where security properties has to be >>>> defined scheme by scheme)? >>> >>> >>> There is no "well defined set of security properties that could apply to any >>> scheme". Security properties necessarily vary depending on the way a >>> resource is used, the threat model, and so forth. >> >> Here I agree with Keith. >> >>> Also, the idea that there should be a "secure" bit in a URI scheme, to >>> distinguish it from the "insecure" form of a URL, doesn't make much sense. >>> You always want to use the best security that's available. >> >> You always want the best security you're willing to pay for. >> >>> You don't want that to depend on the URI scheme. >> >> Ideally not, but in actual operation, it made a lot of sense for HTTP as Roy >> has explained. > I think it made a lot of sense because the port 443 convention meant that you > had to know whether or not to use SSL had to be known before you sent the SYN > packet. > Well, same thing for TURN, as a different default port is used when TLS is used (3478 for TURN over UDP and TCP, and 5349 for TURN over TLS). - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6wW48ACgkQ9RoMZyVa61fPKQCfTLUElFx97Pz8XwQHwkJmJNCh kiEAn3Ew6/LOxc816VpuMWk5hFfKzi5y =c0vN -----END PGP SIGNATURE----- From harald@alvestrand.no Tue Nov 1 13:54:39 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E98821F8DF6; Tue, 1 Nov 2011 13:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thr-M0AunLLZ; Tue, 1 Nov 2011 13:54:39 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F2C3221F8DA4; Tue, 1 Nov 2011 13:54:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1270D39E13B; Tue, 1 Nov 2011 21:44:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8SW1uNsqm46; Tue, 1 Nov 2011 21:44:20 +0100 (CET) Received: from [172.20.78.134] (63-145-238-4.dia.static.qwest.net [63.145.238.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 982C039E04C; Tue, 1 Nov 2011 21:44:18 +0100 (CET) Message-ID: <4EB05A23.3060101@alvestrand.no> Date: Tue, 01 Nov 2011 13:44:19 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> In-Reply-To: <4EAF9391.5040209@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Ned Freed , Keith Moore , Keith Moore , Behave WG , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 20:54:39 -0000 Top-posting a general principle, detailed comment at the bottom.... For all URI schemes, I think the URI needs to contain all the information you need in order to make contact with the service; you can't negotiate until you've made contact. (the process may involve things like "resolve through a resolution mechanism like DNS" or "get authorization tokens from somewhere else"). In the case of TURN, you need to distinguish between TCP, UDP and TLS, and you need to make that determination before you send the first packet. That means the distinguishing information between those three things belongs in the URL; I don't think the scheme is a good place to encode it. On 10/31/2011 11:37 PM, "Martin J. Dürst" wrote: > > > On 2011/11/01 0:33, Keith Moore wrote: >> >> On Oct 31, 2011, at 10:57 AM, Marc Petit-Huguenin wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Hi Martin, >>> >>> So I understand Roy's email as saying in fact the opposite of what >>> Harald said, >>> i.e. that using an "s" suffix to signify security is a good thing. >>> >>> What is your opinion on defining a generic scheme suffix (i.e. "+s" >>> or "+sec") >>> that would indicate a well defined set of security properties that >>> could apply >>> to any scheme, (vs the current "s" suffix where security properties >>> has to be >>> defined scheme by scheme)? >> >> >> There is no "well defined set of security properties that could apply >> to any scheme". Security properties necessarily vary depending on >> the way a resource is used, the threat model, and so forth. > > Here I agree with Keith. > >> Also, the idea that there should be a "secure" bit in a URI scheme, >> to distinguish it from the "insecure" form of a URL, doesn't make >> much sense. You always want to use the best security that's available. > > You always want the best security you're willing to pay for. > >> You don't want that to depend on the URI scheme. > > Ideally not, but in actual operation, it made a lot of sense for HTTP > as Roy has explained. I think it made a lot of sense because the port 443 convention meant that you had to know whether or not to use SSL had to be known before you sent the SYN packet. From rpenno@juniper.net Tue Nov 1 16:14:01 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0136A1F0C47; Tue, 1 Nov 2011 16:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4wzZWowjGsn; Tue, 1 Nov 2011 16:14:00 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 42A341F0C41; Tue, 1 Nov 2011 16:14:00 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP; Tue, 01 Nov 2011 16:14:00 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 1 Nov 2011 16:12:30 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 1 Nov 2011 19:12:28 -0400 From: Reinaldo Penno To: "softwires@ietf.org" , "behave@ietf.org" Date: Tue, 1 Nov 2011 19:12:26 -0400 Thread-Topic: Stateless Deterministic NAPT/DS-Lite Thread-Index: AcyYtLocaKZVJf2RRuq8rhvEWjd6LgANv36b Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 23:14:01 -0000 Hello, we submitted a new draft detailing our implementation of Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT) http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 This is a based on our experience with port bucket/chunk allocation and deterministic NAPT44. In the draft we provide a comparison with other stateless/stateful methods floating around. Thanks, Reinaldo From marka@isc.org Tue Nov 1 17:51:10 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71B71F0C47 for ; Tue, 1 Nov 2011 17:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRABFuvkm695 for ; Tue, 1 Nov 2011 17:51:10 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 130091F0C38 for ; Tue, 1 Nov 2011 17:51:10 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id B8B125F9899; Wed, 2 Nov 2011 00:50:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0BE94216C6D; Wed, 2 Nov 2011 00:50:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1D2F6166A615; Wed, 2 Nov 2011 11:50:48 +1100 (EST) To: "Dan Wing" From: Mark Andrews References: <4EAF0384.1050002@gmail.com> <1be201cc98b3$249d7a90$6dd86fb0$@com> In-reply-to: Your message of "Tue, 01 Nov 2011 09:27:26 PDT." <1be201cc98b3$249d7a90$6dd86fb0$@com> Date: Wed, 02 Nov 2011 11:50:47 +1100 Message-Id: <20111102005048.1D2F6166A615@drugs.dv.isc.org> Cc: 'Prashanth Patil' , behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 00:51:10 -0000 The best way to identify a mapped response is for the DNS64 server to flag it and as *every* IPv6 node is supposed to be EDNS capable a EDNS option can be used to signal this. getaddrinfo would just filter DNS64 responses when it is asking for both address families. Dual stack applications would just see the IPv4 addresses. IPv6 only apps would see the mapped addresses. Recursive servers talking to forwarders would set the option on AAAA queries and record the respone along with any AAAA records. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From simon.perreault@viagenie.ca Tue Nov 1 18:04:02 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A745A1F0C6C for ; Tue, 1 Nov 2011 18:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhGgsrSiITT0 for ; Tue, 1 Nov 2011 18:04:02 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 1947F1F0C38 for ; Tue, 1 Nov 2011 18:04:02 -0700 (PDT) Received: from banana.viagenie.ca (unknown [173.243.43.162]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BB7DB20D01; Tue, 1 Nov 2011 21:03:59 -0400 (EDT) Message-ID: <4EB096FE.6050703@viagenie.ca> Date: Tue, 01 Nov 2011 21:03:58 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Olivier Vautrin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" , Dan Wing , Benson Schliesser Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 01:04:02 -0000 Olivier Vautrin wrote, on 11/01/2011 01:32 AM: > I agree. What about "SHOULD" support per-connection if logging is not > needed. "SHOULD" support bulk port allocation if Logging is needed. But we don't necessarily need bulk port allocation even when logging is needed. See for example draft-donley-behave-deterministic-cgn, which significantly reduces the need for logging without bulk port allocation (even if it does work well with bulk port allocation). Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From cb.list6@gmail.com Tue Nov 1 18:38:41 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FB421F9E00 for ; Tue, 1 Nov 2011 18:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.904 X-Spam-Level: X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=0.694, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBkkE5WgimSO for ; Tue, 1 Nov 2011 18:38:40 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF81C21F9DFE for ; Tue, 1 Nov 2011 18:38:38 -0700 (PDT) Received: by qadc10 with SMTP id c10so8102715qad.31 for ; Tue, 01 Nov 2011 18:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0WtNQ20eCwWnLDS5StqLZ4z3ew8O2iFGZRqdrLx54H0=; b=k6B+dCshTUDi2doP2dwAK1iss+pDD4piHxBe0FdvEv4hHPktbG0Jnqj5hQ+5RCyfZr p11gob0YUT4a4LhsZXZ9ptrUFdLqDIK8lNag9OgxC3jNSll/GmW3DpnyDEj9xbr/FCjP nIfveJ9SkU35DKXsIzwzCaulMDGmEzWPTzT/g= MIME-Version: 1.0 Received: by 10.182.164.74 with SMTP id yo10mr430205obb.69.1320197918096; Tue, 01 Nov 2011 18:38:38 -0700 (PDT) Received: by 10.182.72.41 with HTTP; Tue, 1 Nov 2011 18:38:37 -0700 (PDT) Received: by 10.182.72.41 with HTTP; Tue, 1 Nov 2011 18:38:37 -0700 (PDT) In-Reply-To: <4EB096FE.6050703@viagenie.ca> References: <4EB096FE.6050703@viagenie.ca> Date: Tue, 1 Nov 2011 18:38:37 -0700 Message-ID: From: Cameron Byrne To: Simon Perreault Content-Type: multipart/alternative; boundary=e89a8f646acff0fe4904b0b687e8 Cc: "behave@ietf.org" , Olivier Vautrin , Dan Wing , Benson Schliesser Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 01:38:41 -0000 --e89a8f646acff0fe4904b0b687e8 Content-Type: text/plain; charset=ISO-8859-1 On Nov 1, 2011 6:04 PM, "Simon Perreault" wrote: > > Olivier Vautrin wrote, on 11/01/2011 01:32 AM: > > I agree. What about "SHOULD" support per-connection if logging is not > > needed. "SHOULD" support bulk port allocation if Logging is needed. > > But we don't necessarily need bulk port allocation even when logging is needed. > See for example draft-donley-behave-deterministic-cgn, which significantly > reduces the need for logging without bulk port allocation (even if it does work > well with bulk port allocation). > Sounds to me there is no ONE recommendation. That being the case, no recommendation should be made unless their is a desire to account for all the combinations with pros and cons, or cover this topic in seperate document. Cb > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --e89a8f646acff0fe4904b0b687e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 1, 2011 6:04 PM, "Simon Perreault" <simon.perreault@viagenie.ca> wrote:
>
> Olivier Vautrin wrote, on 11/01/2011 01:32 AM:
> > I agree. What about "SHOULD" support per-connection if = logging is not
> > needed. "SHOULD" support bulk port allocation if Loggin= g is needed.
>
> But we don't necessarily need bulk port allocation even when loggi= ng is needed.
> See for example draft-donley-behave-deterministic-cgn, which significa= ntly
> reduces the need for logging without bulk port allocation (even if it = does work
> well with bulk port allocation).
>

Sounds to me there is no ONE recommendation. That being the case, no rec= ommendation should be made unless their is a desire to account for all the = combinations with pros and cons, or cover this topic in seperate document.<= /p>

Cb
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
> STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave

--e89a8f646acff0fe4904b0b687e8-- From simon.perreault@viagenie.ca Tue Nov 1 18:44:59 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7611E8081 for ; Tue, 1 Nov 2011 18:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EAfaUC5GZkn for ; Tue, 1 Nov 2011 18:44:59 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 267891F0C55 for ; Tue, 1 Nov 2011 18:44:59 -0700 (PDT) Received: from banana.viagenie.ca (unknown [173.243.43.162]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 60DC921CB6; Tue, 1 Nov 2011 21:44:58 -0400 (EDT) Message-ID: <4EB0A094.6050805@viagenie.ca> Date: Tue, 01 Nov 2011 21:44:52 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Cameron Byrne References: <4EB096FE.6050703@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" , Olivier Vautrin , Dan Wing , Benson Schliesser Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 01:44:59 -0000 Cameron Byrne wrote, on 11/01/2011 09:38 PM: > Sounds to me there is no ONE recommendation. That being the case, no > recommendation should be made unless their is a desire to account for all the > combinations with pros and cons, or cover this topic in seperate document. Yes, that's what I was getting to. I don't think we have enough operational experience at this point to make a recommendation that will stand. People seem to be exploring all directions, which is good, but I think that we need to move on and stay with the "no normative text" guidance we had at the last meeting. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From kawashimam@vx.jp.nec.com Tue Nov 1 22:08:00 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012911F0C71; Tue, 1 Nov 2011 22:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIp2RbgkF7m9; Tue, 1 Nov 2011 22:07:59 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id D65FF1F0C64; Tue, 1 Nov 2011 22:07:58 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id pA257vc1026121; Wed, 2 Nov 2011 14:07:57 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id pA257uH08679; Wed, 2 Nov 2011 14:07:56 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id pA257uX8024300; Wed, 2 Nov 2011 14:07:56 +0900 (JST) Received: from chojiro.jp.nec.com ([10.26.220.28] [10.26.220.28]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-1818889; Wed, 2 Nov 2011 14:06:48 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-37724; Wed, 2 Nov 2011 14:06:48 +0900 To: softwires@ietf.org, behave@ietf.org, draft-mawatari-softwire-464xlat@tools.ietf.org Fw: I-D Action: draft-mawatari-softwire-464xlat-02.txt Message-Id: <20111102140648kawashimam@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Wed, 2 Nov 2011 14:06:47 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Request a time slot for 464XLAT presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 05:08:00 -0000 Softwire and Behave Chairs, I have submitted a -02 version regarding 464XLAT. We added usecase of mobile network in this draft. Could you please schedule a time slot for a 464XLAT presentation? Topic : "464XLAT: Combination of Stateful and Stateless Translation" Draft name : draft-mawatari-softwire-464xlat-02 Time needed : 10minutes Presenter's name : Masataka Mawatari Regards, Masanobu ------------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : 464XLAT: Combination of Stateful and Stateless Translation Author(s) : Masataka Mawatari Masanobu Kawashima Cameron Byrne Filename : draft-mawatari-softwire-464xlat-02.txt Pages : 10 Date : 2011-10-31 This document describes a method (464XLAT) for IPv4 connectivity across IPv6 network by combination of stateful translation and stateless translation. 464XLAT is a simple technique to provide IPv4 access service while avoiding encapsulation by using twice IPv4/IPv6 translation standardized in [RFC6145] and [RFC6146]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mawatari-softwire-464xlat-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-mawatari-softwire-464xlat-02.txt _______________________________________________ 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 ------------------------------------ $B!q(B(._.) ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From moore@network-heretics.com Thu Nov 3 12:29:29 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7861F0CAB; Thu, 3 Nov 2011 12:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DsyfF0iiMZq; Thu, 3 Nov 2011 12:29:28 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id A1CBE1F0CB6; Thu, 3 Nov 2011 12:29:28 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 35DA920A74; Thu, 3 Nov 2011 15:29:27 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 03 Nov 2011 15:29:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=oY+zzfrkNq8DL6JrAJJ9F05oL8Y=; b=Gk L1wcw8MLB2QsMu8hHg6u06Pw37yJT1tNSeTQIsbrMfAiApIZLKN+7+KNNyHhbvhb jq9IljEZj3+cY2Wn60iyCeFnSwekD/xX1rjVWYJlq0eoLvOBbADtJPH8UvdZSrp2 DCCK1tIagj8dz7wJ4cuPj1ofNV7U5Sa+dquasTgws= X-Sasl-enc: NkDtGeB2cZwLgDA7TAhiJfVtigovcopaL4XnYFrirMcv 1320348567 Received: from rlmartin.hq.corp.pbs.org (unknown [149.48.225.2]) by mail.messagingengine.com (Postfix) with ESMTPA id EBF928E0FB9; Thu, 3 Nov 2011 15:29:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Thu, 3 Nov 2011 15:29:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) Cc: Keith Moore , "rtcweb@ietf.org" , =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , Ned Freed , Behave WG Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 19:29:29 -0000 On Nov 3, 2011, at 2:58 PM, Eric Rescorla wrote: > On Tue, Nov 1, 2011 at 5:05 AM, Keith Moore = wrote: >>> In most cases probably not. But there may be cases similar to HTTP/S = where it makes sense. Each case has to be analyzed independently. >>=20 >> agree. I just don't think it's a good idea to establish a new = _convention_. >=20 > i don't really understand what you're arguing here. >=20 > The relevant issue is that we want to have a reference that Bob can = provide > to Alice that guarantees that when it's dereferenced it provides a = minimum > set of security properties. >=20 > Let's imagine some hypothetical new protocol which is like HTTP but = not HTTP, > say HTTQ. It runs over TCP so you can use it directly or over TLS = (i.e., > HTTP/TCP or HTTP/TLS/TCP). We're planning to define a new URI for it, > httq://.../. How do you propose to provide the above security = property? If you're going to define a new protocol, it should always use TLS (or = it should always provide a minimum set of security properties). Then = you define a single URI type for the new protocol, and it doesn't need = the security flag. It's only when you're trying to retro-fit security into an existing = protocol that is already widely used, doesn't inherently provide a = reasonable level of security for that application, and the security = isn't securely negotiated in-band, that you need a security flag in the = URI. More generally, the right place to set the minimum security level is in = the application, not in the name of the resource. The reason you need = https vs. http is that the two are really different protocols, and the = client has to know a priori whether to send "GET..." or to negotiate the = TLS layer after the TCP open completes. =20 Keith From moore@network-heretics.com Thu Nov 3 13:04:25 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3DB1F0C44; Thu, 3 Nov 2011 13:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ9hqxfYr-1J; Thu, 3 Nov 2011 13:04:24 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8B58E1F0C35; Thu, 3 Nov 2011 13:04:18 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 287D320CB9; Thu, 3 Nov 2011 16:04:18 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 03 Nov 2011 16:04:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=Yuvge/hhlTYGTb3ZJHlhQc9wFoU=; b=iu VpANkHw+taNa1E+H8+XRx4UsrPtrr9mmQXo6ASGKVCkXD+LGpqfEsp++TQDKpPr6 lyZ1QxHOQ7dO8/njoxmt+7JOiwvP8roGFAknnfzfgqjiFpDbMm9PvuTUx6vw/fIt s6qe8qGQ63jyTzcxnC6hoTD9hyWNCJyxv9eeFWqLA= X-Sasl-enc: +fm0sdn4wbjRC/p3pzC5SmorQpFZE9Sh5UB+lgUaUK5b 1320350657 Received: from rlmartin.hq.corp.pbs.org (unknown [149.48.225.2]) by mail.messagingengine.com (Postfix) with ESMTPA id B7C658E102B; Thu, 3 Nov 2011 16:04:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Thu, 3 Nov 2011 16:04:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) Cc: Keith Moore , "rtcweb@ietf.org" , =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , Ned Freed , Behave WG Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 20:04:25 -0000 On Nov 3, 2011, at 3:43 PM, Eric Rescorla wrote: >> More generally, the right place to set the minimum security level is = in the application, not in the name of the resource. The reason you = need https vs. http is that the two are really different protocols, and = the client has to know a priori whether to send "GET..." or to negotiate = the TLS layer after the TCP open completes. >=20 > I don't agree with this, however. The reason you need https: versus > http: is that it's the server providing the reference and it's the > only one that knows whether the resource is to be accessed over TLS or > not. Right, but it has to communicate that information to the client somehow, = and the URI is really the only place to do it. =20 > As a point of historical trivia, the initial use of this general > convention wasn't https:// but rather shttp://, and the intent of the > originator, Allan Schiffman, was to make it impossible for a > non-Secure HTTP capable client to accidentally reference via HTTP a > resource which should be secure. I wasn't aware of the originator's name, but certainly agree with the = intent. =20 There's a huge problem with in-band negotiation of security if either = (a) it's feasible for an attacker to get the client to downgrade to = insufficient security, or (b) it's so much work for the client to = negotiate good security that clients tend to be lazy and not bother to = even try.=20 One thing I find fairly annoying about URIs in that we'd really like to = be able to attach attributes and/or constraints to a URI (like what the = minimum security requirements should be) for the purpose of things like = bookmarks, but we don't have a uniform URI syntax that lets us define = such attributes and/or constraints while still being able to easily = separate them from the name of the resource being referred to. Keith From kristian.poscic@alcatel-lucent.com Thu Nov 3 16:38:39 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3AA11E80DE; Thu, 3 Nov 2011 16:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BP1scbtvQycK; Thu, 3 Nov 2011 16:38:39 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0A64A11E8089; Thu, 3 Nov 2011 16:38:38 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pA3Nca2O002288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2011 18:38:37 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA3NcZYb026520 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Nov 2011 18:38:35 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 3 Nov 2011 18:38:35 -0500 From: "Poscic, Kristian (Kristian)" To: Reinaldo Penno , "softwires@ietf.org" , "behave@ietf.org" Date: Thu, 3 Nov 2011 18:38:29 -0500 Thread-Topic: [BEHAVE] Stateless Deterministic NAPT/DS-Lite Thread-Index: AcyYtLocaKZVJf2RRuq8rhvEWjd6LgANv36bAGUxOqA= Message-ID: <2073A6C5467C99478898544C6EBA3F4602BD2809D2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 23:38:39 -0000 Just to make sure I understand this.=20 Deterministic (statefull) NAT is deterministically translating inside IP to= outside IP + port range (take NAT44 case). Deterministic stateLESS NAT is deterministically translating inside IP + in= side_src_port to outside IP + outside_src_port.=20 No states are required since the incoming traffic in the downstream directi= on (outside IP +port) can be deterministically translated to inside IP+port= .=20 Any incoming traffic from outside will be mapped to something (predictable)= on the inside even though there may be no traffic initiated from the insid= e. CPE still needs statefull NAT. Is this correct? Thanks, Kris -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Reinaldo Penno Sent: Tuesday, November 01, 2011 4:12 PM To: softwires@ietf.org; behave@ietf.org Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite Hello, we submitted a new draft detailing our implementation of Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT) http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 This is a based on our experience with port bucket/chunk allocation and deterministic NAPT44. In the draft we provide a comparison with other stateless/stateful methods floating around. Thanks, Reinaldo _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From rpenno@juniper.net Thu Nov 3 17:34:03 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D60411E80C5; Thu, 3 Nov 2011 17:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoFgEbqvOi+X; Thu, 3 Nov 2011 17:34:03 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 917B611E80BF; Thu, 3 Nov 2011 17:34:01 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP; Thu, 03 Nov 2011 17:34:02 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 3 Nov 2011 17:32:54 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 3 Nov 2011 20:32:53 -0400 From: Reinaldo Penno To: "Poscic, Kristian (Kristian)" , "softwires@ietf.org" , "behave@ietf.org" Date: Thu, 3 Nov 2011 20:32:51 -0400 Thread-Topic: [BEHAVE] Stateless Deterministic NAPT/DS-Lite Thread-Index: AcyYtLocaKZVJf2RRuq8rhvEWjd6LgANv36bAGUxOqAAAjL2jA== Message-ID: In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602BD2809D2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 00:34:03 -0000 Hello Kristian, comments inline. On 11/3/11 4:38 PM, "Poscic, Kristian (Kristian)" wrote: > Just to make sure I understand this. >=20 > Deterministic (statefull) NAT is deterministically translating inside IP = to > outside IP + port range (take NAT44 case). Yes.=20 >=20 > Deterministic stateLESS NAT is deterministically translating inside IP + > inside_src_port to outside IP + outside_src_port. > No states are required since the incoming traffic in the downstream direc= tion > (outside IP +port) can be deterministically translated to inside IP+port. > Any incoming traffic from outside will be mapped to something (predictabl= e) on > the inside even though there may be no traffic initiated from the inside. Correct, no need for previous outbound packet. Subscriber gets port forwarding naturally as a consequence. >=20 > CPE still needs statefull NAT. >=20 > Is this correct? Yes. > Thanks, > Kris >=20 >=20 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of > Reinaldo Penno > Sent: Tuesday, November 01, 2011 4:12 PM > To: softwires@ietf.org; behave@ietf.org > Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite >=20 > Hello, >=20 > we submitted a new draft detailing our implementation of > Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT) >=20 > http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 >=20 > This is a based on our experience with port bucket/chunk allocation and > deterministic NAPT44. In the draft we provide a comparison with other > stateless/stateful methods floating around. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From wim.henderickx@alcatel-lucent.com Thu Nov 3 23:21:13 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF691F0C41; Thu, 3 Nov 2011 23:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGlmnEwPH45g; Thu, 3 Nov 2011 23:21:13 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 281411F0C3D; Thu, 3 Nov 2011 23:21:07 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pA46L5Q2023459 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Nov 2011 07:21:05 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.42]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 4 Nov 2011 07:21:05 +0100 From: "Henderickx, Wim (Wim)" To: Reinaldo Penno , "Poscic, Kristian (Kristian)" , "softwires@ietf.org" , "behave@ietf.org" Date: Fri, 4 Nov 2011 07:21:04 +0100 Thread-Topic: [BEHAVE] Stateless Deterministic NAPT/DS-Lite Thread-Index: AcyYtLocaKZVJf2RRuq8rhvEWjd6LgANv36bAGUxOqAAAjL2jAAMIOow Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D671B85F60E@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <2073A6C5467C99478898544C6EBA3F4602BD2809D2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 06:21:14 -0000 Reinaldo, What happens if a customer wants to get more ports than the CPE owns? How would PCP operate with this model? Cheers, Wim -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Reinaldo Penno Sent: vrijdag 4 november 2011 1:33 To: Poscic, Kristian (Kristian); softwires@ietf.org; behave@ietf.org Subject: Re: [Softwires] [BEHAVE] Stateless Deterministic NAPT/DS-Lite Hello Kristian, comments inline. On 11/3/11 4:38 PM, "Poscic, Kristian (Kristian)" wrote: > Just to make sure I understand this. >=20 > Deterministic (statefull) NAT is deterministically translating inside IP = to > outside IP + port range (take NAT44 case). Yes.=20 >=20 > Deterministic stateLESS NAT is deterministically translating inside IP + > inside_src_port to outside IP + outside_src_port. > No states are required since the incoming traffic in the downstream direc= tion > (outside IP +port) can be deterministically translated to inside IP+port. > Any incoming traffic from outside will be mapped to something (predictabl= e) on > the inside even though there may be no traffic initiated from the inside. Correct, no need for previous outbound packet. Subscriber gets port forwarding naturally as a consequence. >=20 > CPE still needs statefull NAT. >=20 > Is this correct? Yes. > Thanks, > Kris >=20 >=20 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of > Reinaldo Penno > Sent: Tuesday, November 01, 2011 4:12 PM > To: softwires@ietf.org; behave@ietf.org > Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite >=20 > Hello, >=20 > we submitted a new draft detailing our implementation of > Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT) >=20 > http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 >=20 > This is a based on our experience with port bucket/chunk allocation and > deterministic NAPT44. In the draft we provide a comparison with other > stateless/stateful methods floating around. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From ekr@rtfm.com Thu Nov 3 12:00:07 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379E911E8132; Thu, 3 Nov 2011 12:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLpj8djo82ED; Thu, 3 Nov 2011 12:00:06 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B31311E811A; Thu, 3 Nov 2011 12:00:06 -0700 (PDT) Received: by gye5 with SMTP id 5so1881890gye.31 for ; Thu, 03 Nov 2011 12:00:05 -0700 (PDT) Received: by 10.146.124.10 with SMTP id w10mr2115061yac.13.1320346779246; Thu, 03 Nov 2011 11:59:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.232.12 with HTTP; Thu, 3 Nov 2011 11:58:57 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> From: Eric Rescorla Date: Thu, 3 Nov 2011 11:58:57 -0700 Message-ID: To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 04 Nov 2011 08:59:03 -0700 Cc: Keith Moore , "rtcweb@ietf.org" , =?ISO-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= , Ned Freed , Behave WG Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 19:00:07 -0000 On Tue, Nov 1, 2011 at 5:05 AM, Keith Moore wr= ote: >> In most cases probably not. But there may be cases similar to HTTP/S whe= re it makes sense. Each case has to be analyzed independently. > > agree. =A0I just don't think it's a good idea to establish a new _convent= ion_. i don't really understand what you're arguing here. The relevant issue is that we want to have a reference that Bob can provide to Alice that guarantees that when it's dereferenced it provides a minimum set of security properties. Let's imagine some hypothetical new protocol which is like HTTP but not HTT= P, say HTTQ. It runs over TCP so you can use it directly or over TLS (i.e., HTTP/TCP or HTTP/TLS/TCP). We're planning to define a new URI for it, httq://.../. How do you propose to provide the above security property? -Ekr From ekr@rtfm.com Thu Nov 3 12:05:17 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148981F0CC9; Thu, 3 Nov 2011 12:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaurtazNu9Y6; Thu, 3 Nov 2011 12:05:16 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAD31F0CC6; Thu, 3 Nov 2011 12:05:16 -0700 (PDT) Received: by mail-yw0-f44.google.com with SMTP id 2so1894100ywt.31 for ; Thu, 03 Nov 2011 12:05:16 -0700 (PDT) Received: by 10.100.5.19 with SMTP id 19mr2513483ane.60.1320347110925; Thu, 03 Nov 2011 12:05:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.232.12 with HTTP; Thu, 3 Nov 2011 11:54:13 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <8E6C5B0D-2161-4D14-9BEE-7B41998CDB7E@network-heretics.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <8E6C5B0D-2161-4D14-9BEE-7B41998CDB7E@network-heretics.com> From: Eric Rescorla Date: Thu, 3 Nov 2011 11:54:13 -0700 Message-ID: To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 04 Nov 2011 08:59:03 -0700 Cc: Keith Moore , Harald Alvestrand , Ned Freed , Behave WG , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 19:05:17 -0000 On Sat, Oct 29, 2011 at 9:44 PM, Keith Moore w= rote: > > On Oct 30, 2011, at 12:40 AM, Harald Alvestrand wrote: > >> On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 10/29/2011 03:36 PM, I=F1aki Baz Castillo wrote: >>>> 2011/10/29 Harald Alvestrand: >>>>> - I do not think it's appropriate to use "turn" and "turns" for indic= ating >>>>> transport. Polluting the URI namespace with more configuration parame= ters in >>>>> the form of trailing "s" is a Bad Thing. >>>> But there should be some way to indicate that a TURN server listens in >>>> TLS, right? >>>> >>> We should continue this discussion in BEHAVE, but I would like to ask t= he OP to >>> send a pointer on the RFC or discussion that says that using a trailing= "s" to >>> indicate security is a bad thing. >> I'll have to forward this question to the apps ADs of a few years ago ab= out whether there's documentation for it. It does not seem to have been cap= tured in an RFC that I can find; discussion was in the ~2000-2005 timeframe= . >> >> The short version, from memory: Doing "s" locks you into one and exactly= one security scheme, and prevents you from saying anything about the requi= site parameters for that scheme, while using AUTH parameters such as POP or= in-band negotiation such as IMAP =A0are much more flexible approaches. > > Security schemes change over time as new (presumably better) ones appear,= and vulnerabilities are discovered in old ones. =A0 There's nothing inhere= ntly wrong with having a URI scheme end in "s". =A0But it's a Bad Idea to p= romote the notion that "s" means "security". What the "s" means is "Connect via TLS and check the server cert". People are free to infer whatever they want about the level of "security" provided. -Ekr From ekr@rtfm.com Thu Nov 3 12:54:06 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF3011E80AE; Thu, 3 Nov 2011 12:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5haqR-opkEd; Thu, 3 Nov 2011 12:54:05 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5927321F843B; Thu, 3 Nov 2011 12:54:05 -0700 (PDT) Received: by ywt2 with SMTP id 2so1942922ywt.31 for ; Thu, 03 Nov 2011 12:54:05 -0700 (PDT) Received: by 10.146.137.34 with SMTP id k34mr2671990yad.26.1320349431235; Thu, 03 Nov 2011 12:43:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.232.12 with HTTP; Thu, 3 Nov 2011 12:43:10 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> From: Eric Rescorla Date: Thu, 3 Nov 2011 12:43:10 -0700 Message-ID: To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 04 Nov 2011 08:59:03 -0700 Cc: Keith Moore , "rtcweb@ietf.org" , =?ISO-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= , Ned Freed , Behave WG Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 19:54:06 -0000 On Thu, Nov 3, 2011 at 12:29 PM, Keith Moore w= rote: > > On Nov 3, 2011, at 2:58 PM, Eric Rescorla wrote: > >> On Tue, Nov 1, 2011 at 5:05 AM, Keith Moore = wrote: >>>> In most cases probably not. But there may be cases similar to HTTP/S w= here it makes sense. Each case has to be analyzed independently. >>> >>> agree. =A0I just don't think it's a good idea to establish a new _conve= ntion_. >> >> i don't really understand what you're arguing here. >> >> The relevant issue is that we want to have a reference that Bob can prov= ide >> to Alice that guarantees that when it's dereferenced it provides a minim= um >> set of security properties. >> >> Let's imagine some hypothetical new protocol which is like HTTP but not = HTTP, >> say HTTQ. It runs over TCP so you can use it directly or over TLS (i.e., >> HTTP/TCP or HTTP/TLS/TCP). We're planning to define a new URI for it, >> httq://.../. How do you propose to provide the above security property? > > If you're going to define a new protocol, it should always use TLS (or it= should always provide a minimum set of security properties). =A0Then you d= efine a single URI type for the new protocol, and it doesn't need the secur= ity flag. OK. I agree with this. > It's only when you're trying to retro-fit security into an existing proto= col that is already widely used, doesn't inherently provide a reasonable le= vel of security for that application, and the security isn't securely negot= iated in-band, that you need a security flag in the URI. Sure. > More generally, the right place to set the minimum security level is in t= he application, not in the name of the resource. =A0The reason you need htt= ps vs. http is that the two are really different protocols, and the client = has to know a priori whether to send "GET..." or to negotiate the TLS layer= after the TCP open completes. I don't agree with this, however. The reason you need https: versus http: is that it's the server providing the reference and it's the only one that knows whether the resource is to be accessed over TLS or not. As a point of historical trivia, the initial use of this general convention wasn't https:// but rather shttp://, and the intent of the originator, Allan Schiffman, was to make it impossible for a non-Secure HTTP capable client to accidentally reference via HTTP a resource which should be secure. -Ekr From ekr@rtfm.com Fri Nov 4 08:56:58 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61F321F8B7B; Fri, 4 Nov 2011 08:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ3CsaOzw8rw; Fri, 4 Nov 2011 08:56:58 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F22A421F8B49; Fri, 4 Nov 2011 08:56:57 -0700 (PDT) Received: by vws5 with SMTP id 5so220460vws.31 for ; Fri, 04 Nov 2011 08:56:54 -0700 (PDT) Received: by 10.52.65.14 with SMTP id t14mr13419980vds.47.1320422214081; Fri, 04 Nov 2011 08:56:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Fri, 4 Nov 2011 08:56:13 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <01O80L7NM7N000RCTX@mauve.mrochek.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> From: Eric Rescorla Date: Fri, 4 Nov 2011 08:56:13 -0700 Message-ID: To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 04 Nov 2011 08:59:03 -0700 Cc: Harald Alvestrand , Keith Moore , Keith Moore , Behave WG , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 15:56:58 -0000 On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed wrote: >> Top-posting a general principle, detailed comment at the bottom.... > >> For all URI schemes, I think the URI needs to contain all the >> information you need in order to make contact with the service; you >> can't negotiate until you've made contact. >> (the process may involve things like "resolve through a resolution >> mechanism like DNS" or "get authorization tokens from somewhere else"). > >> In the case of TURN, you need to distinguish between TCP, UDP and TLS, >> and you need to make that determination before you send the first >> packet. That means the distinguishing information between those three >> things belongs in the URL; I don't think the scheme is a good place to >> encode it. > > I'm in complete agreement with Harald on all of these points. And while it > would have been nice if URL syntax was less messy and more general, making > it easier to do these sorts of things in a consistent way, it quite simply > isn't and we have to make do with what we have. I don't have any commitment to the scheme. What's the best place? -Ekr From ned.freed@mrochek.com Fri Nov 4 08:36:31 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E23721F8A71; Fri, 4 Nov 2011 08:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf0RaQaiQio2; Fri, 4 Nov 2011 08:36:30 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C4CC421F8A70; Fri, 4 Nov 2011 08:36:30 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O80L7PEC340183VD@mauve.mrochek.com>; Fri, 4 Nov 2011 08:33:43 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O7ZO5R0F0G00RCTX@mauve.mrochek.com>; Fri, 4 Nov 2011 08:33:40 -0700 (PDT) Message-id: <01O80L7NM7N000RCTX@mauve.mrochek.com> Date: Fri, 04 Nov 2011 08:31:20 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 01 Nov 2011 13:44:19 -0700" <4EB05A23.3060101@alvestrand.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> To: Harald Alvestrand X-Mailman-Approved-At: Fri, 04 Nov 2011 08:59:15 -0700 Cc: Ned Freed , Keith Moore , Keith Moore , "rtcweb@ietf.org" , =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Behave WG Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 15:36:31 -0000 > Top-posting a general principle, detailed comment at the bottom.... > For all URI schemes, I think the URI needs to contain all the > information you need in order to make contact with the service; you > can't negotiate until you've made contact. > (the process may involve things like "resolve through a resolution > mechanism like DNS" or "get authorization tokens from somewhere else"). > In the case of TURN, you need to distinguish between TCP, UDP and TLS, > and you need to make that determination before you send the first > packet. That means the distinguishing information between those three > things belongs in the URL; I don't think the scheme is a good place to > encode it. I'm in complete agreement with Harald on all of these points. And while it would have been nice if URL syntax was less messy and more general, making it easier to do these sorts of things in a consistent way, it quite simply isn't and we have to make do with what we have. Ned From dwing@cisco.com Fri Nov 4 09:06:20 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD2C21F8CA1; Fri, 4 Nov 2011 09:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.578 X-Spam-Level: X-Spam-Status: No, score=-105.578 tagged_above=-999 required=5 tests=[AWL=1.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dewo4gp7akOA; Fri, 4 Nov 2011 09:06:19 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0F421F8C9E; Fri, 4 Nov 2011 09:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1860; q=dns/txt; s=iport; t=1320422779; x=1321632379; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=9m+Vvi+nxuAvN6Wd+QzSkVe5onXVhRKd5pV73Wmdcuk=; b=ZGqrHYxB6kl/vM6ueQp83jvjLMpKP258aE6R55v16VQzLc9PbiVwbrJQ Oikmxc8fX46AFQrAl+Db3T6JVGHnDwrwtu3HxIaCojWaLyECINEOJ7TWh G0StqggpZ/4YhC9gFVB3989jOHK4R2tpXCBBYFqn1cUqfX7tC7T4wGQrE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskAAE8NtE6rRDoJ/2dsb2JhbABEmhCBa4xogSCBBYFyAQEBBAEBAQUKARcQNAsMAQMCCQ4BAgQBAQEnBxkOFQoJCAEBBAESCxeHaJZ5AZ5ciSsEiAqeGA X-IronPort-AV: E=Sophos;i="4.69,456,1315180800"; d="scan'208";a="12370910" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 04 Nov 2011 16:06:07 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA4G67gs000440; Fri, 4 Nov 2011 16:06:07 GMT From: "Dan Wing" To: "'Eric Rescorla'" , "'Ned Freed'" References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> In-Reply-To: Date: Fri, 4 Nov 2011 09:06:07 -0700 Message-ID: <02a901cc9b0b$a9638940$fc2a9bc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcybCmTMk2kTkttER/CHovfDIrg3zwAAQ4Zw Content-Language: en-us Cc: 'Behave WG' , 'Keith Moore' , 'Keith Moore' , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:06:20 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Friday, November 04, 2011 8:56 AM > To: Ned Freed > Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org > Subject: Re: [rtcweb] URI schemes for TURN and STUN > > On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed > wrote: > >> Top-posting a general principle, detailed comment at the bottom.... > > > >> For all URI schemes, I think the URI needs to contain all the > >> information you need in order to make contact with the service; you > >> can't negotiate until you've made contact. > >> (the process may involve things like "resolve through a resolution > >> mechanism like DNS" or "get authorization tokens from somewhere > else"). > > > >> In the case of TURN, you need to distinguish between TCP, UDP and > TLS, > >> and you need to make that determination before you send the first > >> packet. That means the distinguishing information between those > three > >> things belongs in the URL; I don't think the scheme is a good place > to > >> encode it. > > > > I'm in complete agreement with Harald on all of these points. And > while it > > would have been nice if URL syntax was less messy and more general, > making > > it easier to do these sorts of things in a consistent way, it quite > simply > > isn't and we have to make do with what we have. > > I don't have any commitment to the scheme. What's the best place? http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05 uses "?transport=", for example: turn://example.com?transport=tcp turns://example.com?transport=udp -d > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From petithug@acm.org Fri Nov 4 09:17:33 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE5F21F8C1E; Fri, 4 Nov 2011 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.721 X-Spam-Level: X-Spam-Status: No, score=-102.721 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5HDOoI-sG3F; Fri, 4 Nov 2011 09:17:32 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6017521F8C34; Fri, 4 Nov 2011 09:17:32 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3FE3220595; Fri, 4 Nov 2011 16:08:30 +0000 (UTC) Message-ID: <4EB41016.7080205@acm.org> Date: Fri, 04 Nov 2011 09:17:26 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Dan Wing References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <02a901cc9b0b$a9638940$fc2a9bc0$@com> In-Reply-To: <02a901cc9b0b$a9638940$fc2a9bc0$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Eric Rescorla' , 'Behave WG' , 'Keith Moore' , 'Keith Moore' , 'Ned Freed' , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:17:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/04/2011 09:06 AM, Dan Wing wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Eric Rescorla >> Sent: Friday, November 04, 2011 8:56 AM >> To: Ned Freed >> Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org >> Subject: Re: [rtcweb] URI schemes for TURN and STUN >> >> On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed >> wrote: >>>> Top-posting a general principle, detailed comment at the bottom.... >>> >>>> For all URI schemes, I think the URI needs to contain all the >>>> information you need in order to make contact with the service; you >>>> can't negotiate until you've made contact. >>>> (the process may involve things like "resolve through a resolution >>>> mechanism like DNS" or "get authorization tokens from somewhere >> else"). >>> >>>> In the case of TURN, you need to distinguish between TCP, UDP and >> TLS, >>>> and you need to make that determination before you send the first >>>> packet. That means the distinguishing information between those >> three >>>> things belongs in the URL; I don't think the scheme is a good place >> to >>>> encode it. >>> >>> I'm in complete agreement with Harald on all of these points. And >> while it >>> would have been nice if URL syntax was less messy and more general, >> making >>> it easier to do these sorts of things in a consistent way, it quite >> simply >>> isn't and we have to make do with what we have. >> >> I don't have any commitment to the scheme. What's the best place? > > http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05 > uses "?transport=", for example: > > turn://example.com?transport=tcp > turns://example.com?transport=udp The document uses opaque URI (there was a long discussion at the time about this), so it is in fact: turn:example.com?transport=tcp turns:example.com?transport=udp - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk60EBIACgkQ9RoMZyVa61fG4wCeLR4SnIoXerj7ONxM6QeKgjZh rmoAmwbBUDmL6YOlnfH1sWsC6a6R+4Bz =Iqfa -----END PGP SIGNATURE----- From dwing@cisco.com Fri Nov 4 09:40:06 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB14821F8B94; Fri, 4 Nov 2011 09:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.596 X-Spam-Level: X-Spam-Status: No, score=-105.596 tagged_above=-999 required=5 tests=[AWL=1.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbbuJGXFTloa; Fri, 4 Nov 2011 09:40:06 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 292EF21F8B8C; Fri, 4 Nov 2011 09:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2916; q=dns/txt; s=iport; t=1320424806; x=1321634406; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=3FFzVr98U5iKNxQRdySfKo7z7wk+XmW1xyA0wTBuqm8=; b=Ky+/EwIDsoseEhF/uq0n/FiMHQNvn/1FeOOqaCEVVw61eIHjzCTaR4O9 PZEO9VknNSxdo/reIRRvvYfpJ0+s9/xbbCIFs2MBKj8sMV7Cz8vlWRwAd q8jVowI5gVemaJYJlVdcsZPcPoM9UUGm3q5axBXCL1jqhcXWbYCUNcjoq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskAAEEVtE6rRDoH/2dsb2JhbABEhHqVFoFrjGiBIIEFgXIBAQEECAoBEAdPDAEDAgkPAgQBAQECAiMDAgIZIwoJCAEBBBMLF4dolxoBjEuSDYEwhmWBFgSICp4Y X-IronPort-AV: E=Sophos;i="4.69,456,1315180800"; d="scan'208";a="12392035" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 04 Nov 2011 16:40:05 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA4Ge5Qx011233; Fri, 4 Nov 2011 16:40:05 GMT From: "Dan Wing" To: "'Marc Petit-Huguenin'" References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <02a901cc9b0b$a9638940$fc2a9bc0$@com> <4EB41016.7080205@acm.org> In-Reply-To: <4EB41016.7080205@acm.org> Date: Fri, 4 Nov 2011 09:40:05 -0700 Message-ID: <02be01cc9b10$6816f9e0$3844eda0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcybDUFWu8RSTTcyS+O+hnVed8FuKwAAxdIw Content-Language: en-us Cc: 'Eric Rescorla' , 'Behave WG' , 'Keith Moore' , 'Keith Moore' , 'Ned Freed' , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:40:07 -0000 > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@acm.org] > Sent: Friday, November 04, 2011 9:17 AM > To: Dan Wing > Cc: 'Eric Rescorla'; 'Ned Freed'; 'Behave WG'; 'Keith Moore'; 'Keith > Moore'; rtcweb@ietf.org > Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/04/2011 09:06 AM, Dan Wing wrote: > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Eric Rescorla > >> Sent: Friday, November 04, 2011 8:56 AM > >> To: Ned Freed > >> Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org > >> Subject: Re: [rtcweb] URI schemes for TURN and STUN > >> > >> On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed > >> wrote: > >>>> Top-posting a general principle, detailed comment at the > bottom.... > >>> > >>>> For all URI schemes, I think the URI needs to contain all the > >>>> information you need in order to make contact with the service; > you > >>>> can't negotiate until you've made contact. > >>>> (the process may involve things like "resolve through a resolution > >>>> mechanism like DNS" or "get authorization tokens from somewhere > >> else"). > >>> > >>>> In the case of TURN, you need to distinguish between TCP, UDP and > >> TLS, > >>>> and you need to make that determination before you send the first > >>>> packet. That means the distinguishing information between those > >> three > >>>> things belongs in the URL; I don't think the scheme is a good > place > >> to > >>>> encode it. > >>> > >>> I'm in complete agreement with Harald on all of these points. And > >> while it > >>> would have been nice if URL syntax was less messy and more general, > >> making > >>> it easier to do these sorts of things in a consistent way, it quite > >> simply > >>> isn't and we have to make do with what we have. > >> > >> I don't have any commitment to the scheme. What's the best place? > > > > http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05 > > uses "?transport=", for example: > > > > turn://example.com?transport=tcp > > turns://example.com?transport=udp > > The document uses opaque URI (there was a long discussion at the time > about > this), so it is in fact: > > turn:example.com?transport=tcp > turns:example.com?transport=udp Thanks for the correction. (some examples in the I-D would be useful, to avoid mistakes like mine.) -d > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk60EBIACgkQ9RoMZyVa61fG4wCeLR4SnIoXerj7ONxM6QeKgjZh > rmoAmwbBUDmL6YOlnfH1sWsC6a6R+4Bz > =Iqfa > -----END PGP SIGNATURE----- From ekr@rtfm.com Fri Nov 4 09:43:18 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FD411E8086; Fri, 4 Nov 2011 09:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XneiaqgoENNT; Fri, 4 Nov 2011 09:43:17 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B845411E8082; Fri, 4 Nov 2011 09:43:17 -0700 (PDT) Received: by gye5 with SMTP id 5so3070057gye.31 for ; Fri, 04 Nov 2011 09:43:16 -0700 (PDT) Received: by 10.150.190.10 with SMTP id n10mr15665085ybf.70.1320424996087; Fri, 04 Nov 2011 09:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.232.12 with HTTP; Fri, 4 Nov 2011 09:42:35 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <02a901cc9b0b$a9638940$fc2a9bc0$@com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <02a901cc9b0b$a9638940$fc2a9bc0$@com> From: Eric Rescorla Date: Fri, 4 Nov 2011 09:42:35 -0700 Message-ID: To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keith Moore , Ned Freed , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:43:18 -0000 On Fri, Nov 4, 2011 at 9:06 AM, Dan Wing wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Eric Rescorla >> Sent: Friday, November 04, 2011 8:56 AM >> To: Ned Freed >> Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org >> Subject: Re: [rtcweb] URI schemes for TURN and STUN >> >> On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed >> wrote: >> >> Top-posting a general principle, detailed comment at the bottom.... >> > >> >> For all URI schemes, I think the URI needs to contain all the >> >> information you need in order to make contact with the service; you >> >> can't negotiate until you've made contact. >> >> (the process may involve things like "resolve through a resolution >> >> mechanism like DNS" or "get authorization tokens from somewhere >> else"). >> > >> >> In the case of TURN, you need to distinguish between TCP, UDP and >> TLS, >> >> and you need to make that determination before you send the first >> >> packet. That means the distinguishing information between those >> three >> >> things belongs in the URL; I don't think the scheme is a good place >> to >> >> encode it. >> > >> > I'm in complete agreement with Harald on all of these points. And >> while it >> > would have been nice if URL syntax was less messy and more general, >> making >> > it easier to do these sorts of things in a consistent way, it quite >> simply >> > isn't and we have to make do with what we have. >> >> I don't have any commitment to the scheme. What's the best place? > > http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05 > uses "?transport=3D", for example: > > =A0turn://example.com?transport=3Dtcp > =A0turns://example.com?transport=3Dudp I'm confused. I thought the idea was to distinguish TLS from non-TLS, but you seem to be doing that in the scheme. -Ekr From petithug@acm.org Fri Nov 4 09:49:37 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC74A11E8082; Fri, 4 Nov 2011 09:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.706 X-Spam-Level: X-Spam-Status: No, score=-102.706 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5WgsAgstQpQ; Fri, 4 Nov 2011 09:49:37 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id DD34111E8081; Fri, 4 Nov 2011 09:49:36 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A19BD20595; Fri, 4 Nov 2011 16:40:35 +0000 (UTC) Message-ID: <4EB4179C.9050703@acm.org> Date: Fri, 04 Nov 2011 09:49:32 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Dan Wing References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <02a901cc9b0b$a9638940$fc2a9bc0$@com> <4EB41016.7080205@acm.org> <02be01cc9b10$6816f9e0$3844eda0$@com> In-Reply-To: <02be01cc9b10$6816f9e0$3844eda0$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Eric Rescorla' , 'Behave WG' , 'Keith Moore' , 'Keith Moore' , 'Ned Freed' , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:49:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/04/2011 09:40 AM, Dan Wing wrote: >> -----Original Message----- >> From: Marc Petit-Huguenin [mailto:petithug@acm.org] >> Sent: Friday, November 04, 2011 9:17 AM >> To: Dan Wing >> Cc: 'Eric Rescorla'; 'Ned Freed'; 'Behave WG'; 'Keith Moore'; 'Keith >> Moore'; rtcweb@ietf.org >> Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN >> > On 11/04/2011 09:06 AM, Dan Wing wrote: >>>>> -----Original Message----- >>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>> Behalf Of Eric Rescorla >>>>> Sent: Friday, November 04, 2011 8:56 AM >>>>> To: Ned Freed >>>>> Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org >>>>> Subject: Re: [rtcweb] URI schemes for TURN and STUN >>>>> >>>>> On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed >>>>> wrote: >>>>>>> Top-posting a general principle, detailed comment at the > bottom.... >>>>>> >>>>>>> For all URI schemes, I think the URI needs to contain all the >>>>>>> information you need in order to make contact with the service; > you >>>>>>> can't negotiate until you've made contact. >>>>>>> (the process may involve things like "resolve through a resolution >>>>>>> mechanism like DNS" or "get authorization tokens from somewhere >>>>> else"). >>>>>> >>>>>>> In the case of TURN, you need to distinguish between TCP, UDP and >>>>> TLS, >>>>>>> and you need to make that determination before you send the first >>>>>>> packet. That means the distinguishing information between those >>>>> three >>>>>>> things belongs in the URL; I don't think the scheme is a good > place >>>>> to >>>>>>> encode it. >>>>>> >>>>>> I'm in complete agreement with Harald on all of these points. And >>>>> while it >>>>>> would have been nice if URL syntax was less messy and more general, >>>>> making >>>>>> it easier to do these sorts of things in a consistent way, it quite >>>>> simply >>>>>> isn't and we have to make do with what we have. >>>>> >>>>> I don't have any commitment to the scheme. What's the best place? >>>> >>>> http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05 >>>> uses "?transport=", for example: >>>> >>>> turn://example.com?transport=tcp >>>> turns://example.com?transport=udp > > The document uses opaque URI (there was a long discussion at the time > about > this), so it is in fact: > > turn:example.com?transport=tcp > turns:example.com?transport=udp > >> Thanks for the correction. > >> (some examples in the I-D would be useful, to avoid mistakes like mine.) Will do. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk60F5oACgkQ9RoMZyVa61ccqQCePrkokWQlZIpgRImOVnUngs9Q w34An2U9EgwpFclj98m6MJl68GAkziIz =qrda -----END PGP SIGNATURE----- From dwing@cisco.com Fri Nov 4 09:53:44 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF8121F8B84; Fri, 4 Nov 2011 09:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.614 X-Spam-Level: X-Spam-Status: No, score=-105.614 tagged_above=-999 required=5 tests=[AWL=0.985, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ukHfcYv5LD5; Fri, 4 Nov 2011 09:53:44 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 04FF721F8B7A; Fri, 4 Nov 2011 09:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2605; q=dns/txt; s=iport; t=1320425623; x=1321635223; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=keQN27SFU7jMNb+nq99Nz52/d2Dm5ac/t1hImCdFXEk=; b=Thc+xil7v7PXBxtTIHX0fojyJzYtF+Dt4nUgV1Bgpe5pAVZWq9+fEScJ RKAsK5wgjNS4cA1vMK+ZGasSQ8nCZcBE9lzm+5rKCrWuxfyDdhOoFNGCA ZNKCVGA3T5HfI6U2shJuPhXdVl6k6yVS0Bey3WEuy2IWfgSumaPe0udRT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskAAPEXtE6rRDoI/2dsb2JhbABEmhCBa4xogSCBBYFyAQEBAwEICgEXTwwBAwIJDgECBAEBAScHGSMKCQgBAQQTCxeHYAiXIwGeU4krBIdZMZ4Y X-IronPort-AV: E=Sophos;i="4.69,456,1315180800"; d="scan'208";a="10977601" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 04 Nov 2011 16:53:43 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA4GrfBK011647; Fri, 4 Nov 2011 16:53:42 GMT From: "Dan Wing" To: "'Eric Rescorla'" References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <02a901cc9b0b$a9638940$fc2a9bc0$@com> In-Reply-To: Date: Fri, 4 Nov 2011 09:53:41 -0700 Message-ID: <02d801cc9b12$4ef4bb80$ecde3280$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcybENwFGD02H39KSmeHmaD54VpzsgAAKUXg Content-Language: en-us Cc: 'Keith Moore' , 'Ned Freed' , 'Keith Moore' , 'Behave WG' , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:53:44 -0000 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Friday, November 04, 2011 9:43 AM > To: Dan Wing > Cc: Ned Freed; Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org > Subject: Re: [rtcweb] URI schemes for TURN and STUN >=20 > On Fri, Nov 4, 2011 at 9:06 AM, Dan Wing wrote: > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Eric Rescorla > >> Sent: Friday, November 04, 2011 8:56 AM > >> To: Ned Freed > >> Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org > >> Subject: Re: [rtcweb] URI schemes for TURN and STUN > >> > >> On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed > >> wrote: > >> >> Top-posting a general principle, detailed comment at the > bottom.... > >> > > >> >> For all URI schemes, I think the URI needs to contain all the > >> >> information you need in order to make contact with the service; > you=09 > >> >> can't negotiate until you've made contact. > >> >> (the process may involve things like "resolve through a > resolution > >> >> mechanism like DNS" or "get authorization tokens from somewhere > >> else"). > >> > > >> >> In the case of TURN, you need to distinguish between TCP, UDP = and > >> TLS, > >> >> and you need to make that determination before you send the = first > >> >> packet. That means the distinguishing information between those > >> three > >> >> things belongs in the URL; I don't think the scheme is a good > place > >> to > >> >> encode it. > >> > > >> > I'm in complete agreement with Harald on all of these points. And > >> while it > >> > would have been nice if URL syntax was less messy and more > general, > >> making > >> > it easier to do these sorts of things in a consistent way, it > quite > >> simply > >> > isn't and we have to make do with what we have. > >> > >> I don't have any commitment to the scheme. What's the best place? > > > > = http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05 > > uses "?transport=3D", for example: > > > > =A0turn://example.com?transport=3Dtcp > > =A0turns://example.com?transport=3Dudp >=20 > I'm confused. I thought the idea was to distinguish TLS from non-TLS, > but you seem to be doing that in the scheme. Harald said: URI needs to contain all the information you need in order to make contact with the service; you can't negotiate until you've made contact. Keith has never liked using "S" in HTTPS (or other URIs). *shrug*. I think that ship sailed. -d From harald@alvestrand.no Fri Nov 4 17:18:41 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C11F1F0C46; Fri, 4 Nov 2011 17:18:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr66SdXI630M; Fri, 4 Nov 2011 17:18:39 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 846331F0C35; Fri, 4 Nov 2011 17:18:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B99939E0CD; Sat, 5 Nov 2011 01:18:38 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQjvfL0MPuqW; Sat, 5 Nov 2011 01:18:37 +0100 (CET) Received: from [10.154.240.196] (unknown [62.206.113.61]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7E79F39E08B; Sat, 5 Nov 2011 01:18:37 +0100 (CET) Message-ID: <4EB480E7.1010200@alvestrand.no> Date: Sat, 05 Nov 2011 01:18:47 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Eric Rescorla References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Keith Moore , Ned Freed , Keith Moore , Behave WG , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 00:18:41 -0000 On 11/04/2011 04:56 PM, Eric Rescorla wrote: > On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed wrote: >>> Top-posting a general principle, detailed comment at the bottom.... >>> For all URI schemes, I think the URI needs to contain all the >>> information you need in order to make contact with the service; you >>> can't negotiate until you've made contact. >>> (the process may involve things like "resolve through a resolution >>> mechanism like DNS" or "get authorization tokens from somewhere else"). >>> In the case of TURN, you need to distinguish between TCP, UDP and TLS, >>> and you need to make that determination before you send the first >>> packet. That means the distinguishing information between those three >>> things belongs in the URL; I don't think the scheme is a good place to >>> encode it. >> I'm in complete agreement with Harald on all of these points. And while it >> would have been nice if URL syntax was less messy and more general, making >> it easier to do these sorts of things in a consistent way, it quite simply >> isn't and we have to make do with what we have. > I don't have any commitment to the scheme. What's the best place? I like parameters, like this: turn://user@host?proto=tcp Quite hard to misunderstand, and quite easy to extend. (Note: // is only allowed if what follows is [user[:pass]@]host - I don't recommend using the password, for the obvious reasons, but the syntax will allow it.) > -Ekr > From ekr@rtfm.com Sat Nov 5 07:31:32 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D42C21F84C2; Sat, 5 Nov 2011 07:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-NA+PJWrVjk; Sat, 5 Nov 2011 07:31:31 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8520B21F84C1; Sat, 5 Nov 2011 07:31:31 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so3351912vcb.31 for ; Sat, 05 Nov 2011 07:31:31 -0700 (PDT) Received: by 10.52.65.14 with SMTP id t14mr17367185vds.47.1320503491065; Sat, 05 Nov 2011 07:31:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Sat, 5 Nov 2011 07:30:51 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <4EB480E7.1010200@alvestrand.no> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> From: Eric Rescorla Date: Sat, 5 Nov 2011 07:30:51 -0700 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: Keith Moore , Ned Freed , Keith Moore , Behave WG , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 14:31:32 -0000 On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand wrote: > On 11/04/2011 04:56 PM, Eric Rescorla wrote: >> I don't have any commitment to the scheme. What's the best place? > > I like parameters, like this: > > turn://user@host?proto=tcp > > Quite hard to misunderstand, and quite easy to extend. > > (Note: // is only allowed if what follows is [user[:pass]@]host - I don't > recommend using the password, for the obvious reasons, but the syntax will > allow it.) I don't see any security problem with that. The "break old implementations" rationale doesn't apply when we are defining a new URI scheme. -Ekr From gsalguei@cisco.com Sat Nov 5 08:04:43 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A732721F8A66 for ; Sat, 5 Nov 2011 08:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zuCt7fRopxO for ; Sat, 5 Nov 2011 08:04:43 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id EAB7B21F8A62 for ; Sat, 5 Nov 2011 08:04:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pA5F4f9T022229 for ; Sat, 5 Nov 2011 11:04:42 -0400 (EDT) Received: from rtp-gsalguei-8712.cisco.com (rtp-gsalguei-8712.cisco.com [10.116.61.51]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pA5F4dTS016108; Sat, 5 Nov 2011 11:04:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-132-748379258 From: Gonzalo Salgueiro In-Reply-To: Date: Sat, 5 Nov 2011 11:04:39 -0400 Message-Id: <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) Cc: Ned Freed , Keith Moore , Gonzalo Salgueiro , Harald Alvestrand , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 15:04:43 -0000 --Apple-Mail-132-748379258 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: > On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand = wrote: >> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >=20 >>> I don't have any commitment to the scheme. What's the best place? >>=20 >> I like parameters, like this: >>=20 >> turn://user@host?proto=3Dtcp >>=20 >> Quite hard to misunderstand, and quite easy to extend. >>=20 >> (Note: // is only allowed if what follows is [user[:pass]@]host - I = don't >> recommend using the password, for the obvious reasons, but the syntax = will >> allow it.) >=20 > I don't see any security problem with that. The "break old > implementations" rationale > doesn't apply when we are defining a new URI scheme. I agree with this as well. If we can get some consensus with this, I = will update the next version of both the STUN and TURN URI Scheme drafts = to include this format. Regards, Gonzalo >=20 > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --Apple-Mail-132-748379258 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand = <harald@alvestrand.no> = wrote:
On 11/04/2011 04:56 PM, Eric = Rescorla wrote:

I don't have any commitment to the scheme. What's the best = place?

I like = parameters, like this:

turn://user@host?proto=3Dtcp
=

Quite hard to misunderstand, and quite easy to = extend.

(Note: // is = only allowed if what follows is [user[:pass]@]host - I = don't
recommend using the = password, for the obvious reasons, but the syntax = will
allow = it.)

I don't see any security problem with that. The = "break old
implementations" rationale
doesn't apply when we are = defining a new URI scheme.

I agree = with this as well.  If we can get some consensus with this, I will = update the next version of both the STUN and TURN URI Scheme drafts to = include this = format.

Regards,

Gonzalo=


-Ekr
___________________________________________= ____
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb


= --Apple-Mail-132-748379258-- From petithug@acm.org Sat Nov 5 08:15:02 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDDB21F8A69; Sat, 5 Nov 2011 08:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.685 X-Spam-Level: X-Spam-Status: No, score=-102.685 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3aV8Aj8kPFw; Sat, 5 Nov 2011 08:15:01 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C091021F8A71; Sat, 5 Nov 2011 08:15:01 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8E02E200D1; Sat, 5 Nov 2011 15:05:56 +0000 (UTC) Message-ID: <4EB552F0.6050800@acm.org> Date: Sat, 05 Nov 2011 08:14:56 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Gonzalo Salgueiro References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> In-Reply-To: <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Eric Rescorla , Ned Freed , Keith Moore , Harald Alvestrand , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 15:15:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: > > On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: > >> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand > > wrote: >>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >> >>>> I don't have any commitment to the scheme. What's the best place? >>> >>> I like parameters, like this: >>> >>> turn://user@host?proto=tcp >>> >>> Quite hard to misunderstand, and quite easy to extend. >>> >>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't >>> recommend using the password, for the obvious reasons, but the syntax will >>> allow it.) >> >> I don't see any security problem with that. The "break old >> implementations" rationale >> doesn't apply when we are defining a new URI scheme. > > I agree with this as well. If we can get some consensus with this, I will > update the next version of both the STUN and TURN URI Scheme drafts to include > this format. Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already doing it right (and had a lot of reviews back in 2008, before I split the resolution mechanism and the syntax in two separate documents). I know my email address does not contain the magical "cisco.com", but this is getting ridiculous. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk61Uu4ACgkQ9RoMZyVa61eFrQCgiw1H8kTxgpd90sV1OYuSg3tN B+cAnA9V/XhzV3MAg93WOxpKIAvwk/Nu =jYZJ -----END PGP SIGNATURE----- From gsalguei@cisco.com Sat Nov 5 08:28:43 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2770E21F899F for ; Sat, 5 Nov 2011 08:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dArHUTdUdGwM for ; Sat, 5 Nov 2011 08:28:42 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 5650621F8494 for ; Sat, 5 Nov 2011 08:28:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pA5FSfI2024308 for ; Sat, 5 Nov 2011 11:28:41 -0400 (EDT) Received: from rtp-gsalguei-8712.cisco.com (rtp-gsalguei-8712.cisco.com [10.116.61.51]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pA5FSeps027057; Sat, 5 Nov 2011 11:28:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-133-749820295 From: Gonzalo Salgueiro In-Reply-To: <4EB552F0.6050800@acm.org> Date: Sat, 5 Nov 2011 11:28:40 -0400 Message-Id: References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: Eric Rescorla , Ned Freed , Keith Moore , Gonzalo Salgueiro , Harald Alvestrand , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 15:28:43 -0000 --Apple-Mail-133-749820295 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 5, 2011, at 11:14 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >>=20 >> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >>=20 >>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand = >> > wrote: >>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >>>=20 >>>>> I don't have any commitment to the scheme. What's the best place? >>>>=20 >>>> I like parameters, like this: >>>>=20 >>>> turn://user@host?proto=3Dtcp >>>>=20 >>>> Quite hard to misunderstand, and quite easy to extend. >>>>=20 >>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I = don't >>>> recommend using the password, for the obvious reasons, but the = syntax will >>>> allow it.) >>>=20 >>> I don't see any security problem with that. The "break old >>> implementations" rationale >>> doesn't apply when we are defining a new URI scheme. >>=20 >> I agree with this as well. If we can get some consensus with this, I = will >> update the next version of both the STUN and TURN URI Scheme drafts = to include >> this format. >=20 > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is = already > doing it right (and had a lot of reviews back in 2008, before I split = the > resolution mechanism and the syntax in two separate documents). >=20 I was under the impression (based on an exchange with Cullen) that you = had no plans to pass user credentials in the URI scheme you were = proposing. I'm perfectly OK with whatever the group decides. = Nonetheless, the change makes change to me for one or both drafts. > I know my email address does not contain the magical "cisco.com", but = this is > getting ridiculous. I have no idea where this came from, so I'll choose to leave it alone. Regards, Gonzalo >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iEYEARECAAYFAk61Uu4ACgkQ9RoMZyVa61eFrQCgiw1H8kTxgpd90sV1OYuSg3tN > B+cAnA9V/XhzV3MAg93WOxpKIAvwk/Nu > =3DjYZJ > -----END PGP SIGNATURE----- >=20 --Apple-Mail-133-749820295 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1

On 11/05/2011 08:04 AM, Gonzalo Salgueiro = wrote:

On Nov 5, 2011, at 10:30 AM, Eric Rescorla = wrote:

On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand <harald@alvestrand.no
<mailto:harald@alvestrand.no>&g= t; wrote:
On = 11/04/2011 04:56 PM, Eric Rescorla = wrote:

I don't have any commitment to = the scheme. What's the best = place?

I like = parameters, like = this:

turn://user@host?proto=3Dtcp
=

Quite = hard to misunderstand, and quite easy to = extend.

(Note: = // is only allowed if what follows is [user[:pass]@]host - I = don't
recommend using the password, for the obvious reasons, but = the syntax will
allow = it.)

I don't see any security problem = with that. The "break old
implementations" = rationale
doesn't apply when we are = defining a new URI scheme.

I agree with = this as well.  If we can get some consensus with this, I = will
update the next version = of both the STUN and TURN URI Scheme drafts to = include
this = format.

Or you can look at = draft-petithuguenin-behave-turn-uri-bis, which is already
doing it = right (and had a lot of reviews back in 2008, before I split = the
resolution mechanism and the syntax in two separate = documents).

I was under the impression (based = on an exchange with Cullen) that you had no plans to pass user = credentials in the URI scheme you were proposing. I'm perfectly OK with = whatever the group decides. Nonetheless, the change makes change to me = for one or both drafts.

I = know my email address does not contain the magical "cisco.com", but this is
getting = ridiculous.

I have no idea where = this came from, so I'll choose to leave it = alone.

Regards,

Gonzalo<= /div>


- --
Marc = Petit-Huguenin
Personal email: marc@petit-huguenin.org
Pro= fessional email: petithug@acm.org
Blog: http://blog.marc.petit-huguen= in.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 = (GNU/Linux)

iEYEARECAAYFAk61Uu4ACgkQ9RoMZyVa61eFrQCgiw1H8kTxgpd90sV= 1OYuSg3tN
B+cAnA9V/XhzV3MAg93WOxpKIAvwk/Nu
=3DjYZJ
-----END PGP = SIGNATURE-----


= --Apple-Mail-133-749820295-- From petithug@acm.org Sat Nov 5 08:45:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CF221F8770; Sat, 5 Nov 2011 08:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAX7TdgMvKEc; Sat, 5 Nov 2011 08:45:11 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C4C7021F85EF; Sat, 5 Nov 2011 08:45:10 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 71B10200D1; Sat, 5 Nov 2011 15:36:05 +0000 (UTC) Message-ID: <4EB55A01.70900@acm.org> Date: Sat, 05 Nov 2011 08:45:05 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Gonzalo Salgueiro References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Eric Rescorla , Ned Freed , Keith Moore , Harald Alvestrand , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 15:45:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/05/2011 08:28 AM, Gonzalo Salgueiro wrote: > > On Nov 5, 2011, at 11:14 AM, Marc Petit-Huguenin wrote: > > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >>>> >>>> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >>>> >>>>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand >>>> >>>>> > wrote: >>>>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >>>>> >>>>>>> I don't have any commitment to the scheme. What's the best place? >>>>>> >>>>>> I like parameters, like this: >>>>>> >>>>>> turn://user@host?proto=tcp >>>>>> >>>>>> Quite hard to misunderstand, and quite easy to extend. >>>>>> >>>>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't >>>>>> recommend using the password, for the obvious reasons, but the syntax will >>>>>> allow it.) >>>>> >>>>> I don't see any security problem with that. The "break old >>>>> implementations" rationale >>>>> doesn't apply when we are defining a new URI scheme. >>>> >>>> I agree with this as well. If we can get some consensus with this, I will >>>> update the next version of both the STUN and TURN URI Scheme drafts to include >>>> this format. > > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already > doing it right (and had a lot of reviews back in 2008, before I split the > resolution mechanism and the syntax in two separate documents). > >> I was under the impression (based on an exchange with Cullen) that you had no >> plans to pass user credentials in the URI scheme you were proposing. Yes, and you can count me as opposing user credentials in *any* new URI. >> I'm >> perfectly OK with whatever the group decides. Nonetheless, the change makes >> change to me for one or both drafts. > > I know my email address does not contain the magical "cisco.com > ", but this is > getting ridiculous. > >> I have no idea where this came from, so I'll choose to leave it alone. > >> Regards, > >> Gonzalo > > >> - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk61WgAACgkQ9RoMZyVa61dvDACfd9Aco1hi/jupuRXAyKA41s4x fzYAn2fpCMY/e5e0POFk+t4PY0lijX6O =sI2K -----END PGP SIGNATURE----- From ned.freed@mrochek.com Sat Nov 5 10:26:52 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE03221F8510; Sat, 5 Nov 2011 10:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If1iotYQ8Zol; Sat, 5 Nov 2011 10:26:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 53F8F21F8509; Sat, 5 Nov 2011 10:26:52 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O823CW8SQO0180LI@mauve.mrochek.com>; Sat, 5 Nov 2011 10:24:05 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O7WPUFOG6O00XBUL@mauve.mrochek.com>; Sat, 5 Nov 2011 10:24:02 -0700 (PDT) Message-id: <01O823CUB1SG00XBUL@mauve.mrochek.com> Date: Sat, 05 Nov 2011 10:20:51 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 05 Nov 2011 01:18:47 +0100" <4EB480E7.1010200@alvestrand.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> To: Harald Alvestrand Cc: Eric Rescorla , Ned Freed , Keith Moore , Keith Moore , Behave WG , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 17:26:52 -0000 > On 11/04/2011 04:56 PM, Eric Rescorla wrote: > > On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed wrote: > >>> Top-posting a general principle, detailed comment at the bottom.... > >>> For all URI schemes, I think the URI needs to contain all the > >>> information you need in order to make contact with the service; you > >>> can't negotiate until you've made contact. > >>> (the process may involve things like "resolve through a resolution > >>> mechanism like DNS" or "get authorization tokens from somewhere else"). > >>> In the case of TURN, you need to distinguish between TCP, UDP and TLS, > >>> and you need to make that determination before you send the first > >>> packet. That means the distinguishing information between those three > >>> things belongs in the URL; I don't think the scheme is a good place to > >>> encode it. > >> I'm in complete agreement with Harald on all of these points. And while it > >> would have been nice if URL syntax was less messy and more general, making > >> it easier to do these sorts of things in a consistent way, it quite simply > >> isn't and we have to make do with what we have. > > I don't have any commitment to the scheme. What's the best place? > I like parameters, like this: > turn://user@host?proto=tcp > Quite hard to misunderstand, and quite easy to extend. > (Note: // is only allowed if what follows is [user[:pass]@]host - I > don't recommend using the password, for the obvious reasons, but the > syntax will allow it.) Given your earlier characterization of the TCP/UDP/TLS distinction being a single axis, I assume you mean that you'd say: turn://user@host?proto=tls and not turns://user@host?proto=tcp I have to say I prefer the parameter approach, but I wonder if these really are along a single axis - is DTLS a possibility here? Ned From ekr@rtfm.com Sat Nov 5 12:46:08 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3518021F8726; Sat, 5 Nov 2011 12:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAV4cosUTokM; Sat, 5 Nov 2011 12:46:07 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B29C21F86A4; Sat, 5 Nov 2011 12:46:07 -0700 (PDT) Received: by ywt2 with SMTP id 2so4336378ywt.31 for ; Sat, 05 Nov 2011 12:46:07 -0700 (PDT) Received: by 10.236.77.163 with SMTP id d23mr26392976yhe.34.1320522367144; Sat, 05 Nov 2011 12:46:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.232.12 with HTTP; Sat, 5 Nov 2011 12:45:26 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <01O823CUB1SG00XBUL@mauve.mrochek.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <01O823CUB1SG00XBUL@mauve.mrochek.com> From: Eric Rescorla Date: Sat, 5 Nov 2011 12:45:26 -0700 Message-ID: To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Harald Alvestrand , Keith Moore , Keith Moore , Behave WG , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 19:46:08 -0000 On Sat, Nov 5, 2011 at 10:20 AM, Ned Freed wrote: >> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >> > On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed =A0wr= ote: >> >>> Top-posting a general principle, detailed comment at the bottom.... >> >>> For all URI schemes, I think the URI needs to contain all the >> >>> information you need in order to make contact with the service; you >> >>> can't negotiate until you've made contact. >> >>> (the process may involve things like "resolve through a resolution >> >>> mechanism like DNS" or "get authorization tokens from somewhere >> >>> else"). >> >>> In the case of TURN, you need to distinguish between TCP, UDP and TL= S, >> >>> and you need to make that determination before you send the first >> >>> packet. That means the distinguishing information between those thre= e >> >>> things belongs in the URL; I don't think the scheme is a good place = to >> >>> encode it. >> >> I'm in complete agreement with Harald on all of these points. And whi= le >> >> it >> >> would have been nice if URL syntax was less messy and more general, >> >> making >> >> it easier to do these sorts of things in a consistent way, it quite >> >> simply >> >> isn't and we have to make do with what we have. >> > I don't have any commitment to the scheme. What's the best place? > >> I like parameters, like this: > >> turn://user@host?proto=3Dtcp > >> Quite hard to misunderstand, and quite easy to extend. > >> (Note: // is only allowed if what follows is [user[:pass]@]host - I >> don't recommend using the password, for the obvious reasons, but the >> syntax will allow it.) > > Given your earlier characterization of the TCP/UDP/TLS distinction being > a single axis, I assume you mean that you'd say: > > =A0turn://user@host?proto=3Dtls > > and not > > =A0turns://user@host?proto=3Dtcp > > I have to say I prefer the parameter approach, but I wonder if these real= ly > are along a single axis - is DTLS a possibility here? TCP/TLS UDP/DTLS TCP/DTLS Are all options. Also, it seems like you might want to run DCCP or SCTP and those work with DTLS and {DTLS,TLS} respectively. So, probably better to make the parameters separate. -Ekr From tireddy@cisco.com Sun Nov 6 02:25:38 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B3521F8494 for ; Sun, 6 Nov 2011 02:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.001, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iEKLSe56Zy7 for ; Sun, 6 Nov 2011 02:25:38 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B055721F848E for ; Sun, 6 Nov 2011 02:25:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=2227; q=dns/txt; s=iport; t=1320575137; x=1321784737; h=mime-version:content-transfer-encoding:subject:date: message-id:references:from:to:cc; bh=0bYIU7r0RjV1IQdlb1niokXn3FxTqCLV4Da6qxz6Wxk=; b=SDHuOc1N7aFTkYTqahxWoo4m0T5g8B2WB0SQHRjzPu4k9OX0YJEzpuCM bd5NYCYKGFcEKRJOsYbYbYIaO74lvMKudsrz0en3CdWXlGpho3EJYMIJ9 LCTQuLu3ja+2J/4YeXTDc0R4g6tDOl1UOO+7JCwz1KFom6abBMx2pRDFq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPpftk5Io8UR/2dsb2JhbAA4CqoSgQWBcgEBAQEDEgEdCj8OAgIBCBEDAQILBhgGARoGLggBAQQBCggIGp1rAZ0zAoV4gk5jBIgJkVKFBIc2 X-IronPort-AV: E=Sophos;i="4.69,464,1315180800"; d="scan'208";a="59267354" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 06 Nov 2011 10:25:34 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA6APXFx012706; Sun, 6 Nov 2011 10:25:33 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 6 Nov 2011 15:55:33 +0530 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: Sun, 6 Nov 2011 15:55:32 +0530 Message-ID: <454A16E4DA86094EB66BB2C1DBBBC018061954AA@XMB-BGL-41B.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt Thread-Index: Acya8yvU1ifJQkOLH0CqHvi+iEm3tAAA/pbgAF2+j7A= References: <20111102005048.1D2F6166A615@drugs.dv.isc.org> From: "Tirumaleswar Reddy (tireddy)" To: , X-OriginalArrivalTime: 06 Nov 2011 10:25:33.0363 (UTC) FILETIME=[6A7A3030:01CC9C6E] Cc: "Prashanth Patil \(praspati\)" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 10:25:38 -0000 The advantage with the proposal suggested in the draft is that it requires no changes to host and DNS64 server. The idea is to provide a framework where, based on changes in host or network characteristics, Relay agents can dynamically inform the DHCPv6 server to update the host with new/updated configuration information. In addition, the concept of informing the DHCPv6 server by the network could be extended to other use cases as well. Just like EDNS0 draft-boucadair-behave-dns-a64-02 proposes a model where A64 record for IPv4-Embedded IPv6 address is used so as to distinguish from native IPv6 address using AAAA records. Our proposed draft ensures that, as per RFC 3484, IPv6 address list (not IPv4-embedded IPv6) followed by IPv4 addresses are provided so that native IPv6 is given higher priority over IPv4. Since IPv4-embedded IPv6 addresses are not provided - there is no need for destination address selection algorithm to pick IPv4 over IPv4-embedded IPv6 addresses, which would require the policy table to be updated with network's IPv6/IPv4 translator's prefix or well-known prefix 64:FF9B::/96 as the lowest Precedence in the address selection rules. --Tiru. ------ Forwarded Message From: Mark Andrews Date: Wed, 02 Nov 2011 11:50:47 +1100 To: Dan Wing Cc: 'Brian E Carpenter' , 'Prashanth Patil' , Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt The best way to identify a mapped response is for the DNS64 server to flag it and as *every* IPv6 node is supposed to be EDNS capable a EDNS option can be used to signal this. getaddrinfo would just filter DNS64 responses when it is asking for both address families. Dual stack applications would just see the IPv4 addresses. IPv6 only apps would see the mapped addresses. Recursive servers talking to forwarders would set the option on AAAA queries and record the respone along with any AAAA records. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org ------ End of Forwarded Message From harald@alvestrand.no Sun Nov 6 08:36:22 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E2A21F8490; Sun, 6 Nov 2011 08:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfEaRExNj-2A; Sun, 6 Nov 2011 08:36:21 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B1D0421F8437; Sun, 6 Nov 2011 08:36:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 077B039E0A3; Sun, 6 Nov 2011 17:36:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5N4uk+uzpTU; Sun, 6 Nov 2011 17:36:20 +0100 (CET) Received: from [10.154.240.196] (unknown [62.206.113.61]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0429439E074; Sun, 6 Nov 2011 17:36:19 +0100 (CET) Message-ID: <4EB6B792.8030207@alvestrand.no> Date: Sun, 06 Nov 2011 17:36:34 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> In-Reply-To: <4EB552F0.6050800@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Eric Rescorla , Ned Freed , Keith Moore , Gonzalo Salgueiro , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 16:36:22 -0000 On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >> >>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand>> > wrote: >>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >>>>> I don't have any commitment to the scheme. What's the best place? >>>> I like parameters, like this: >>>> >>>> turn://user@host?proto=tcp >>>> >>>> Quite hard to misunderstand, and quite easy to extend. >>>> >>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't >>>> recommend using the password, for the obvious reasons, but the syntax will >>>> allow it.) >>> I don't see any security problem with that. The "break old >>> implementations" rationale >>> doesn't apply when we are defining a new URI scheme. >> I agree with this as well. If we can get some consensus with this, I will >> update the next version of both the STUN and TURN URI Scheme drafts to include >> this format. > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already > doing it right (and had a lot of reviews back in 2008, before I split the > resolution mechanism and the syntax in two separate documents). > > I know my email address does not contain the magical "cisco.com", but this is > getting ridiculous. Sorry, some of us were not on BEHAVE in 2008, and missed the previous discussion. From harald@alvestrand.no Sun Nov 6 08:37:56 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CBA21F84ED; Sun, 6 Nov 2011 08:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCheTUJ8ZiSH; Sun, 6 Nov 2011 08:37:55 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9163821F84DC; Sun, 6 Nov 2011 08:37:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2D3639E0A3; Sun, 6 Nov 2011 17:37:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3ejcrwS9F7S; Sun, 6 Nov 2011 17:37:54 +0100 (CET) Received: from [10.154.240.196] (unknown [62.206.113.61]) by eikenes.alvestrand.no (Postfix) with ESMTPS id D904539E074; Sun, 6 Nov 2011 17:37:53 +0100 (CET) Message-ID: <4EB6B7F0.4040001@alvestrand.no> Date: Sun, 06 Nov 2011 17:38:08 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> In-Reply-To: <4EB552F0.6050800@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Eric Rescorla , Ned Freed , Keith Moore , Gonzalo Salgueiro , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 16:37:56 -0000 On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >> >>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand>> > wrote: >>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >>>>> I don't have any commitment to the scheme. What's the best place? >>>> I like parameters, like this: >>>> >>>> turn://user@host?proto=tcp >>>> >>>> Quite hard to misunderstand, and quite easy to extend. >>>> >>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't >>>> recommend using the password, for the obvious reasons, but the syntax will >>>> allow it.) >>> I don't see any security problem with that. The "break old >>> implementations" rationale >>> doesn't apply when we are defining a new URI scheme. >> I agree with this as well. If we can get some consensus with this, I will >> update the next version of both the STUN and TURN URI Scheme drafts to include >> this format. > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already > doing it right (and had a lot of reviews back in 2008, before I split the > resolution mechanism and the syntax in two separate documents). > > I know my email address does not contain the magical "cisco.com", but this is > getting ridiculous. Second opinion: draft-petithuguenin uses TURN and TURNS as scheme names. I still think this is doing it wrong. Harald From harald@alvestrand.no Sun Nov 6 08:42:38 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4274421F8511; Sun, 6 Nov 2011 08:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuyzGVVPJvCa; Sun, 6 Nov 2011 08:42:36 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D523821F84DA; Sun, 6 Nov 2011 08:42:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E01139E0A3; Sun, 6 Nov 2011 17:42:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnEVSOzTp+xU; Sun, 6 Nov 2011 17:42:31 +0100 (CET) Received: from [10.154.240.196] (unknown [62.206.113.61]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 468FE39E074; Sun, 6 Nov 2011 17:42:31 +0100 (CET) Message-ID: <4EB6B904.8050607@alvestrand.no> Date: Sun, 06 Nov 2011 17:42:44 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ned Freed References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <01O823CUB1SG00XBUL@mauve.mrochek.com> In-Reply-To: <01O823CUB1SG00XBUL@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" , Eric Rescorla , Keith Moore , Keith Moore , Behave WG Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 16:42:38 -0000 On 11/05/2011 06:20 PM, Ned Freed wrote: >> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >> > On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed >> wrote: >> >>> Top-posting a general principle, detailed comment at the bottom.... >> >>> For all URI schemes, I think the URI needs to contain all the >> >>> information you need in order to make contact with the service; you >> >>> can't negotiate until you've made contact. >> >>> (the process may involve things like "resolve through a resolution >> >>> mechanism like DNS" or "get authorization tokens from somewhere >> else"). >> >>> In the case of TURN, you need to distinguish between TCP, UDP and >> TLS, >> >>> and you need to make that determination before you send the first >> >>> packet. That means the distinguishing information between those >> three >> >>> things belongs in the URL; I don't think the scheme is a good >> place to >> >>> encode it. >> >> I'm in complete agreement with Harald on all of these points. And >> while it >> >> would have been nice if URL syntax was less messy and more >> general, making >> >> it easier to do these sorts of things in a consistent way, it >> quite simply >> >> isn't and we have to make do with what we have. >> > I don't have any commitment to the scheme. What's the best place? > >> I like parameters, like this: > >> turn://user@host?proto=tcp > >> Quite hard to misunderstand, and quite easy to extend. > >> (Note: // is only allowed if what follows is [user[:pass]@]host - I >> don't recommend using the password, for the obvious reasons, but the >> syntax will allow it.) > > Given your earlier characterization of the TCP/UDP/TLS distinction being > a single axis, I assume you mean that you'd say: > > turn://user@host?proto=tls > > and not > > turns://user@host?proto=tcp I was thinking turn://@?proto= but thought that this was going too far into details. > > I have to say I prefer the parameter approach, but I wonder if these > really > are along a single axis - is DTLS a possibility here? DTLS is a possibility, if the TURN protocol is extended to support it, and would be a fourth parameter value. Currently it's not specified (AFAIK). My opinion is that the URL needs to contain the context that the TURN client needs to know before it can contact the TURN server. There may be options that can reasonably be negotiated in the TURN channel setup procedure; those don't need to be in the URL. My current reading is that with the current TURN spec, the initial packets sent by the user is different for the 3 cases TCP, UDP and TLS. From petithug@acm.org Sun Nov 6 08:58:50 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7041721F851F; Sun, 6 Nov 2011 08:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.653 X-Spam-Level: X-Spam-Status: No, score=-102.653 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34fiz8GP6+3y; Sun, 6 Nov 2011 08:58:49 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBC821F8515; Sun, 6 Nov 2011 08:58:49 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 424AD20138; Sun, 6 Nov 2011 16:49:41 +0000 (UTC) Message-ID: <4EB6BCC5.6020407@acm.org> Date: Sun, 06 Nov 2011 08:58:45 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Harald Alvestrand References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> <4EB6B792.8030207@alvestrand.no> In-Reply-To: <4EB6B792.8030207@alvestrand.no> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Eric Rescorla , Ned Freed , Keith Moore , Gonzalo Salgueiro , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 16:58:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/06/2011 08:36 AM, Harald Alvestrand wrote: > On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >>> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >>> >>>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand>>> > wrote: >>>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >>>>>> I don't have any commitment to the scheme. What's the best place? >>>>> I like parameters, like this: >>>>> >>>>> turn://user@host?proto=tcp >>>>> >>>>> Quite hard to misunderstand, and quite easy to extend. >>>>> >>>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't >>>>> recommend using the password, for the obvious reasons, but the syntax will >>>>> allow it.) >>>> I don't see any security problem with that. The "break old >>>> implementations" rationale >>>> doesn't apply when we are defining a new URI scheme. >>> I agree with this as well. If we can get some consensus with this, I will >>> update the next version of both the STUN and TURN URI Scheme drafts to include >>> this format. >> Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already >> doing it right (and had a lot of reviews back in 2008, before I split the >> resolution mechanism and the syntax in two separate documents). >> >> I know my email address does not contain the magical "cisco.com", but this is >> getting ridiculous. > > Sorry, some of us were not on BEHAVE in 2008, and missed the previous discussion. This is not the problem. The problem is that the authors of the new draft continue to ignore a draft that is the result of BEHAVE, IESG, security, gen-art, ops and other directorate reviews. (To be fair, two employees of Cisco I worked with in the past contacted me to see how to work on this but none of the authors of the draft did). - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk62vMMACgkQ9RoMZyVa61fiSwCfZtnYxYBbxMmebzKwkQa19Uus 7v4AoJiPr0aHYvKAoEUkwJNp7DyvpYVW =r7Po -----END PGP SIGNATURE----- From petithug@acm.org Sun Nov 6 09:19:01 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73AE21F853E; Sun, 6 Nov 2011 09:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.65 X-Spam-Level: X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAjhZSce9ixm; Sun, 6 Nov 2011 09:19:01 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id D236C21F8532; Sun, 6 Nov 2011 09:19:00 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 2876820138; Sun, 6 Nov 2011 17:09:50 +0000 (UTC) Message-ID: <4EB6C17F.50103@acm.org> Date: Sun, 06 Nov 2011 09:18:55 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Ned Freed References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> <4EB6B7F0.4040001@alvestrand.no> <01O83GWH5W5I00XBUL@mauve.mrochek.com> In-Reply-To: <01O83GWH5W5I00XBUL@mauve.mrochek.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Eric Rescorla , Behave WG , Keith Moore , Gonzalo Salgueiro , Harald Alvestrand , Keith Moore , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 17:19:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/06/2011 09:59 AM, Ned Freed wrote: >> On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >> >> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >> >> >> >>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand> >>> > wrote: >> >>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >> >>>>> I don't have any commitment to the scheme. What's the best place? >> >>>> I like parameters, like this: >> >>>> >> >>>> turn://user@host?proto=tcp >> >>>> >> >>>> Quite hard to misunderstand, and quite easy to extend. >> >>>> >> >>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't >> >>>> recommend using the password, for the obvious reasons, but the syntax will >> >>>> allow it.) >> >>> I don't see any security problem with that. The "break old >> >>> implementations" rationale >> >>> doesn't apply when we are defining a new URI scheme. >> >> I agree with this as well. If we can get some consensus with this, I will >> >> update the next version of both the STUN and TURN URI Scheme drafts to include >> >> this format. >> > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already >> > doing it right (and had a lot of reviews back in 2008, before I split the >> > resolution mechanism and the syntax in two separate documents). >> > >> > I know my email address does not contain the magical "cisco.com", but this is >> > getting ridiculous. > >> Second opinion: draft-petithuguenin uses TURN and TURNS as scheme names. >> I still think this is doing it wrong. > > I concur, especially since two different security layers could be used for some > transports in addition to none at all. The security layer needs to be specified > as a parameter. The current syntax was inspired by RFC 3261, but I can put some text about different syntax in the spec for the purpose of the discussion[1]. What parameter name would you propose for that? [1] Note that my point of view, and IMO the first thing that should be discussed, is that a TURN URI is not needed for what RTCWEB wants to do. Why is it better to have a URI (on which we cannot put the password anyway), versus having multiple individual string characters for the security level, transport, host, port, login and password? - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk62wX0ACgkQ9RoMZyVa61cWSgCgnHXs8DWr5BKn1jB9j3+cz5Bf +68AoI0Uk3+TKbcV5OSlG/zRZD6AIXrg =tqtp -----END PGP SIGNATURE----- From gsalguei@cisco.com Sun Nov 6 10:11:05 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D825021F85A1 for ; Sun, 6 Nov 2011 10:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9MlW2VYqR1U for ; Sun, 6 Nov 2011 10:11:04 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id BDAF721F8593 for ; Sun, 6 Nov 2011 10:11:04 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pA6IB3Pr016386 for ; Sun, 6 Nov 2011 13:11:03 -0500 (EST) Received: from rtp-gsalguei-8712.cisco.com (rtp-gsalguei-8712.cisco.com [10.116.61.51]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pA6IAv68020484; Sun, 6 Nov 2011 13:10:57 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-148-845957745 From: Gonzalo Salgueiro In-Reply-To: <4EB6BCC5.6020407@acm.org> Date: Sun, 6 Nov 2011 13:10:57 -0500 Message-Id: <430C8C33-6F5F-4278-ADEB-44D963868DFA@cisco.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> <4EB6B792.8030207@alvestrand.no> <4EB6BCC5.6020407@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: Eric Rescorla , Ned Freed , Keith Moore , Gonzalo Salgueiro , Harald Alvestrand , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 18:11:06 -0000 --Apple-Mail-148-845957745 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 6, 2011, at 11:58 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 11/06/2011 08:36 AM, Harald Alvestrand wrote: >> On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>>=20 >>> On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >>>> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >>>>=20 >>>>> On Fri, Nov 4, 2011 at 5:18 PM, Harald = Alvestrand>>>> > wrote: >>>>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >>>>>>> I don't have any commitment to the scheme. What's the best = place? >>>>>> I like parameters, like this: >>>>>>=20 >>>>>> turn://user@host?proto=3Dtcp >>>>>>=20 >>>>>> Quite hard to misunderstand, and quite easy to extend. >>>>>>=20 >>>>>> (Note: // is only allowed if what follows is [user[:pass]@]host - = I don't >>>>>> recommend using the password, for the obvious reasons, but the = syntax will >>>>>> allow it.) >>>>> I don't see any security problem with that. The "break old >>>>> implementations" rationale >>>>> doesn't apply when we are defining a new URI scheme. >>>> I agree with this as well. If we can get some consensus with this, = I will >>>> update the next version of both the STUN and TURN URI Scheme drafts = to include >>>> this format. >>> Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is = already >>> doing it right (and had a lot of reviews back in 2008, before I = split the >>> resolution mechanism and the syntax in two separate documents). >>>=20 >>> I know my email address does not contain the magical "cisco.com", = but this is >>> getting ridiculous. >>=20 >> Sorry, some of us were not on BEHAVE in 2008, and missed the previous = discussion. >=20 > This is not the problem. The problem is that the authors of the new = draft > continue to ignore a draft that is the result of BEHAVE, IESG, = security, > gen-art, ops and other directorate reviews. (To be fair, two = employees of Cisco > I worked with in the past contacted me to see how to work on this but = none of > the authors of the draft did). >=20 I find it incredible I need to explain anything about ignoring your = draft when in our draft it clearly states: We acknowledge the existence of draft-petithuguenin-behave-turn-uri-bis-04 document as a parallel effort in defining the URI scheme for TURN. Awareness of this draft came late in the process and we have not had to time to reach out to the author of that memo and discuss opportunities to collaborate on a single document. It is our intentions to do so. The discussion you had with Cullen and Dan are known to us but we were = pretty much finished both the STUN and TURN drafts by the time we found = out about your draft. At this point we were waiting for you and Cullen = to discuss the best way forward to meet the needs of WebRTC. We are = happy to combine forces or yield entirely, based on that discussion. Regards, Gonzalo > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iEYEARECAAYFAk62vMMACgkQ9RoMZyVa61fiSwCfZtnYxYBbxMmebzKwkQa19Uus > 7v4AoJiPr0aHYvKAoEUkwJNp7DyvpYVW > =3Dr7Po > -----END PGP SIGNATURE----- >=20 --Apple-Mail-148-845957745 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1

On 11/06/2011 08:36 AM, Harald Alvestrand = wrote:
On 11/05/2011 04:14 PM, Marc = Petit-Huguenin wrote:
-----BEGIN PGP SIGNED = MESSAGE-----
Hash: = SHA1

On 11/05/2011 08:04 AM, Gonzalo = Salgueiro wrote:
On Nov = 5, 2011, at 10:30 AM, Eric Rescorla = wrote:

On Fri, Nov 4, 2011 at 5:18 PM, = Harald Alvestrand<harald@alvestrand.no
<mailto:harald@alvestrand.no>&g= t; =  wrote:
On = 11/04/2011 04:56 PM, Eric Rescorla = wrote:
I don't have any commitment to = the scheme. What's the best = place?
I like parameters, like = this:
=

turn://user@host?proto=3Dtcp
=

Quite = hard to misunderstand, and quite easy to = extend.

(Note: = // is only allowed if what follows is [user[:pass]@]host - I = don't
=
recommend using the password, for the obvious reasons, but = the syntax = will
<= blockquote type=3D"cite">
allow = it.)
<= blockquote type=3D"cite">
I don't see any security problem = with that. The "break = old
implementations" = rationale
doesn't apply when we are = defining a new URI = scheme.
I = agree with this as well.  If we can get some consensus with this, I = will
update = the next version of both the STUN and TURN URI Scheme drafts to = include
this = format.
Or you can look at = draft-petithuguenin-behave-turn-uri-bis, which is = already
doing it right (and had a lot of reviews back in 2008, = before I split the
resolution mechanism and the = syntax in two separate = documents).

I know my email address does not = contain the magical "cisco.com", but = this is
getting = ridiculous.

Sorry, some of = us were not on BEHAVE in 2008, and missed the previous = discussion.

This is not the problem.  The = problem is that the authors of the new draft
continue to ignore a = draft that is the result of BEHAVE, IESG, security,
gen-art, ops and = other directorate reviews.  (To be fair, two employees of = Cisco
I worked with in the past contacted me to see how to work on = this but none of
the authors of the draft = did).


I find it incredible = I need to explain anything about ignoring your draft when in our draft = it clearly states:
   We acknowledge the existence of
   draft-petithuguenin-behave-turn-uri-bis-04 document as a parallel
   effort in defining the URI scheme for TURN.  Awareness of this draft
   came late in the process and we have not had to time to reach out to
   the author of that memo and discuss opportunities to collaborate on a
   single document.  It is our intentions to do so.
The = discussion you had with Cullen and Dan are known to us but we were = pretty much finished both the STUN and TURN drafts by the time we found = out about your draft. At this point we were waiting for you and Cullen = to discuss the best way forward to meet the needs of WebRTC.  We = are happy to combine forces or yield entirely, based on that = discussion.

Regards,

Gon= zalo


- --
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Pro= fessional email: petithug@acm.org
Blog: http://blog.marc.petit-huguen= in.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 = (GNU/Linux)

iEYEARECAAYFAk62vMMACgkQ9RoMZyVa61fiSwCfZtnYxYBbxMmebzK= wkQa19Uus
7v4AoJiPr0aHYvKAoEUkwJNp7DyvpYVW
=3Dr7Po
-----END PGP = SIGNATURE-----


= --Apple-Mail-148-845957745-- From brian.e.carpenter@gmail.com Sun Nov 6 12:20:03 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C53821F853A for ; Sun, 6 Nov 2011 12:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.489 X-Spam-Level: X-Spam-Status: No, score=-103.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta8Ql-F33XAj for ; Sun, 6 Nov 2011 12:20:02 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCF6C21F851A for ; Sun, 6 Nov 2011 12:20:02 -0800 (PST) Received: by iaeo4 with SMTP id o4so6455923iae.31 for ; Sun, 06 Nov 2011 12:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=YWThW+88DedbKWTp9DPXZN0a4TK/hf9sxzvqdw62WG8=; b=WR1nf+kV229n+ofDgy9rNEsbF4s31TuvsM0u8j8DoU2zJW39uExpOG2Lofr80VdEk1 AnzvgRzSRNuD8pQ52B/ckwxUEblu+RrvogN0QXzjrKhR3O03+aNdBdobc1m5ETqFbyR2 5OKoCiS5gls9RfaBdYGsHz8Ehr665e+7L46Kk= Received: by 10.42.135.66 with SMTP id o2mr39960413ict.0.1320610801360; Sun, 06 Nov 2011 12:20:01 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id 3sm30022571pbx.14.2011.11.06.12.19.58 (version=SSLv3 cipher=OTHER); Sun, 06 Nov 2011 12:19:59 -0800 (PST) Message-ID: <4EB6EBEB.2010600@gmail.com> Date: Mon, 07 Nov 2011 09:19:55 +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: <4EAF0384.1050002@gmail.com> <1be201cc98b3$249d7a90$6dd86fb0$@com> In-Reply-To: <1be201cc98b3$249d7a90$6dd86fb0$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 'Prashanth Patil' , behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 20:20:03 -0000 On 2011-11-02 05:27, Dan Wing wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Brian E Carpenter >> Sent: Monday, October 31, 2011 1:22 PM >> To: Prashanth Patil >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure= - >> 00.txt >> >> I don't get it. If a host is dual stacked it can be configured with >> any DNS server, as long as it is not a DNS64. If you can have a >> DNS64 directly visible, and a v4-only DNS server directly visible, >> you are on a dual stack network, so you can also have a dual stack >> DNS server directly visible. >=20 > It is anticipated that a network will have a mix of IPv4-only, > IPv6-only, and dual-stack hosts. The hosts don't know if they > need a 'normal' DNS server or a DNS64, nor do we have a way > to tell them the difference. Indeed not, it is for the DHCPv6 server to ensure that the IPv6-only hosts are pointed to the abnormal DNS server (i.e. the DNS64 server). I'm left very uncomfortable by this kludge. Forcing dual-stack hosts to resolve DNS via IPv4 seems backwards. Also, how will this help on a network that is using RFC 6106? DHCPv6 isn't mandatory afaik. Brian >=20 > This I-D attempts to provide a solution to that problem of a=20 > network with a mix of hosts that need to be configured with a=20 > 'normal' DNS server and DNS64 server. We believe the underlying=20 > idea (to "poke" a host to tell it something changed on the=20 > network) appears to have other applicability beyond the DNS/DNS64 > use-case, as well. >=20 > -d >=20 >=20 >> Regards >> Brian Carpenter >> >> On 2011-11-01 05:05, Prashanth Patil wrote: >>> Hi Brian, >>> The idea behind the proposal is to provision a means by which traffic= >> is >>> sent using IPv4 and not through the IPv6/IPv4 translator. The >> advantage >>> being that if NAT44 and NAT64 are deployed on the same network, it is= >>> preferable to use NAT44 over NAT64 because of scale, performance and >>> application incompatibility issues (e.g., FTP) [RFC6384]. >>> A "normal" DNS server does not have DNS64 capability. The IPv4-mapped= >>> address for this "normal" server ensures that it can be reached only >> by >>> IPv4=C5=A1. So if a host is IPv4-only, it will send a DNS query to th= e >> "normal" >>> server just to get the A records. If the host is dual-stack it will >> also >>> send a DNS query to the "normal" server to get both A and AAAA >> records. If >>> the destination address is an IPv4 address, dual-stack host just >> gets A >>> records but not synthesized AAAA records. So this technique will >> ensure that >>> IPv4 is preferred over the IPv6/IPv4 translator prefix and also gives= >> native >>> IPv6 higher precedence than IPv4. >>> If the host happens to be IPv6 only, then it cannot reach the >> "normal" >>> server because it has IPv4-mapped prefix as explained previously. So >> IPv6 >>> only host can only reach DNS64 server. So this host will send the DNS= >> query >>> to DNS64 to get AAAA records. Based on the destination address the >> host will >>> get IPv4-embedded IPv6 address or just the global IPv6 address. >>> >>> =C5=A1Note: From RFC 6052 >>> =C2=B3When presented with the IPv4-mapped prefix, current versions of= >> Windows and >>> Mac OS generate IPv4 packets, but will not send IPv6 packets.=C2=B2 >>> >>> -Prashanth >>> >>> On 22/10/11 6:20 AM, Brian E Carpenter wrote: >>>> I have a basic question. Why does this draft define a 'normal' >>>> DNS server as one having an IPv4-mapped IPv6 address? >>>> >>>> That seems like a completely *abnormal* DNS server for a dual >>>> stack host. A dual stack host should normally have a DNS server >>>> with a regular IPv6 address that will return both A and AAAA >>>> records if they exist. Normally the server will be dual stacked >>>> anyway, and will return exactly the same response whether the >>>> query arrives via v4 or v6. >>>> >>>> A DNS server which only has an IPv4 address will also return >>>> A and AAAA records if they exist, so there is absolutely no >>>> difference as far as the dual stack host is concerned anyway. >>>> So what is the point in using the IPv4-mapped address? >>>> >>>> Regards >>>> Brian >>>> >>>> On 2011-10-18 11:17, internet-drafts@ietf.org wrote: >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> Title : DHCPv6 Dynamic Re-Configuration >>>>> Author(s) : Dan Wing >>>>> Tirumaleswar Reddy >>>>> Prashanth Patil >>>>> Filename : draft-wing-behave-dhcpv6-reconfigure-00.txt >>>>> Pages : 10 >>>>> Date : 2011-10-17 >>>>> >>>>> Some networks are expected to support IPv4-only, dual-stack, >> and >>>>> IPV6-only hosts at the same time. This makes prioritizing the >> DNS >>>>> servers for hosts tricky due to a heterogeneous mix of protocol= >>>>> stacks causing optimal behavior to occur only when the host >> stack re- >>>>> initializes. The networks infrastructure is usually well >> equipped to >>>>> be aware of single/dual-stack nature of hosts. This >> specification >>>>> extends DHCPv6 so that the DHCPv6 Relay Agent can dynamically >>>>> influence the priority of DNS servers provided to the host, so >> that >>>>> the host can use the optimal DNS server for resolution. >>>>> >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- >> reconfigure-00.t >>>>> xt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> This Internet-Draft can be retrieved at: >>>>> ftp://ftp.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- >> reconfigure-00.tx >>>>> t >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >=20 From ned.freed@mrochek.com Sun Nov 6 16:11:53 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B381C21F853E; Sun, 6 Nov 2011 16:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J33X6H+s972z; Sun, 6 Nov 2011 16:11:49 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id F0DBC21F8497; Sun, 6 Nov 2011 16:11:42 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O83GWJUK8W017HEH@mauve.mrochek.com>; Sun, 6 Nov 2011 10:02:35 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O7WPUFOG6O00XBUL@mauve.mrochek.com>; Sun, 6 Nov 2011 10:02:29 -0800 (PST) Message-id: <01O83GWH5W5I00XBUL@mauve.mrochek.com> Date: Sun, 06 Nov 2011 09:59:11 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 06 Nov 2011 17:38:08 +0100" <4EB6B7F0.4040001@alvestrand.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> <4EB6B7F0.4040001@alvestrand.no> To: Harald Alvestrand Cc: Eric Rescorla , Ned Freed , Keith Moore , Gonzalo Salgueiro , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 00:11:53 -0000 > On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: > >> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: > >> > >>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand >>> > wrote: > >>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: > >>>>> I don't have any commitment to the scheme. What's the best place? > >>>> I like parameters, like this: > >>>> > >>>> turn://user@host?proto=tcp > >>>> > >>>> Quite hard to misunderstand, and quite easy to extend. > >>>> > >>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't > >>>> recommend using the password, for the obvious reasons, but the syntax will > >>>> allow it.) > >>> I don't see any security problem with that. The "break old > >>> implementations" rationale > >>> doesn't apply when we are defining a new URI scheme. > >> I agree with this as well. If we can get some consensus with this, I will > >> update the next version of both the STUN and TURN URI Scheme drafts to include > >> this format. > > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already > > doing it right (and had a lot of reviews back in 2008, before I split the > > resolution mechanism and the syntax in two separate documents). > > > > I know my email address does not contain the magical "cisco.com", but this is > > getting ridiculous. > Second opinion: draft-petithuguenin uses TURN and TURNS as scheme names. > I still think this is doing it wrong. I concur, especially since two different security layers could be used for some transports in addition to none at all. The security layer needs to be specified as a parameter. Ned From Tina.Tsou.Zouting@huawei.com Sun Nov 6 16:15:45 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAD921F849D; Sun, 6 Nov 2011 16:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.229 X-Spam-Level: * X-Spam-Status: No, score=1.229 tagged_above=-999 required=5 tests=[AWL=1.724, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iUWb2kWcxuK; Sun, 6 Nov 2011 16:15:44 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6274D21F86DD; Sun, 6 Nov 2011 16:15:44 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU900K5EKQ0PY@szxga03-in.huawei.com>; Mon, 07 Nov 2011 08:15:36 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU900GS0KQ035@szxga03-in.huawei.com>; Mon, 07 Nov 2011 08:15:36 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW52680; Mon, 07 Nov 2011 08:15:31 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Nov 2011 08:15:29 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 08:15:26 +0800 Date: Mon, 07 Nov 2011 00:15:25 +0000 From: Tina TSOU In-reply-to: <01O83GWH5W5I00XBUL@mauve.mrochek.com> X-Originating-IP: [10.212.245.75] To: Ned Freed , Harald Alvestrand Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [BEHAVE] [rtcweb] URI schemes for TURN and STUN Thread-index: AQHMl91zEzXUT2d8NU6B4cA/vnFGMZWWDw6AgAD8coCAAOy2gIAE7c64//94soCAAIxrgIAA7hCAgAAJcoCAAALfAIABqZQAgAEE/CuAAACG4A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> <4EB6B7F0.4040001@alvestrand.no> <01O83GWH5W5I00XBUL@mauve.mrochek.com> Cc: Eric Rescorla , Behave WG , Keith Moore , Gonzalo Salgueiro , "rtcweb@ietf.org" , Keith Moore Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 00:15:45 -0000 Ned, In line... Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Ned Freed Sent: Sunday, November 06, 2011 9:59 AM To: Harald Alvestrand Cc: Eric Rescorla; Ned Freed; Keith Moore; Gonzalo Salgueiro; Keith Moore; Behave WG; rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN > On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: > >> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: > >> > >>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand >>> > wrote: > >>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: > >>>>> I don't have any commitment to the scheme. What's the best place? > >>>> I like parameters, like this: > >>>> > >>>> turn://user@host?proto=tcp > >>>> > >>>> Quite hard to misunderstand, and quite easy to extend. > >>>> > >>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't > >>>> recommend using the password, for the obvious reasons, but the syntax will > >>>> allow it.) > >>> I don't see any security problem with that. The "break old > >>> implementations" rationale > >>> doesn't apply when we are defining a new URI scheme. > >> I agree with this as well. If we can get some consensus with this, I will > >> update the next version of both the STUN and TURN URI Scheme drafts to include > >> this format. > > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already > > doing it right (and had a lot of reviews back in 2008, before I split the > > resolution mechanism and the syntax in two separate documents). > > > > I know my email address does not contain the magical "cisco.com", but this is > > getting ridiculous. > Second opinion: draft-petithuguenin uses TURN and TURNS as scheme names. > I still think this is doing it wrong. I concur, especially since two different security layers could be used for some transports in addition to none at all. The security layer needs to be specified as a parameter. [TT] Using two different security layers at the same time? Or one or the other? Ned _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From adurand@juniper.net Mon Nov 7 06:58:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBA221F85CE; Mon, 7 Nov 2011 06:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.239 X-Spam-Level: X-Spam-Status: No, score=-106.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwXuPQPIX1QR; Mon, 7 Nov 2011 06:58:07 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 564BC21F8BE4; Mon, 7 Nov 2011 06:58:07 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP; Mon, 07 Nov 2011 06:58:07 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 7 Nov 2011 06:54:07 -0800 From: Alain Durand To: "Henderickx, Wim (Wim)" Date: Mon, 7 Nov 2011 06:54:06 -0800 Thread-Topic: [BEHAVE] Stateless Deterministic NAPT/DS-Lite Thread-Index: AcydXRnSNz2Uorw0Roe9tsMFV4SGdg== Message-ID: <9328FE85-AE27-4F52-832D-5D7890DFDB48@juniper.net> References: <2073A6C5467C99478898544C6EBA3F4602BD2809D2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D671B85F60E@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D671B85F60E@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.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: "softwires@ietf.org" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 14:58:11 -0000 On Nov 4, 2011, at 2:21 AM, Henderickx, Wim (Wim) wrote: > Reinaldo, >=20 > What happens if a customer wants to get more ports than the CPE owns? Similar to the other stateless proposals such a 4rd or divi, there is no pr= ovision to dynamically extend that range allocated by the ISP. The consensus that was expressed a number of time in the wg is that if you = need this flexibility, a stateless solution is the wrong approach, you'd be be better of with a st= ateful solution. > How would PCP operate with this model? This is an interesting question... This should make the life of the PCP ser= ver rather easy, as there will be no state to keep there too. Alain. >=20 > Cheers, > Wim >=20 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Reinaldo Penno > Sent: vrijdag 4 november 2011 1:33 > To: Poscic, Kristian (Kristian); softwires@ietf.org; behave@ietf.org > Subject: Re: [Softwires] [BEHAVE] Stateless Deterministic NAPT/DS-Lite >=20 > Hello Kristian, >=20 > comments inline. >=20 >=20 > On 11/3/11 4:38 PM, "Poscic, Kristian (Kristian)" > wrote: >=20 >> Just to make sure I understand this. >>=20 >> Deterministic (statefull) NAT is deterministically translating inside IP= to >> outside IP + port range (take NAT44 case). >=20 > Yes.=20 >=20 >>=20 >> Deterministic stateLESS NAT is deterministically translating inside IP + >> inside_src_port to outside IP + outside_src_port. >> No states are required since the incoming traffic in the downstream dire= ction >> (outside IP +port) can be deterministically translated to inside IP+port= . >> Any incoming traffic from outside will be mapped to something (predictab= le) on >> the inside even though there may be no traffic initiated from the inside= . >=20 > Correct, no need for previous outbound packet. Subscriber gets port > forwarding naturally as a consequence. >=20 >>=20 >> CPE still needs statefull NAT. >>=20 >> Is this correct? >=20 > Yes. >=20 >> Thanks, >> Kris >>=20 >>=20 >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf= Of >> Reinaldo Penno >> Sent: Tuesday, November 01, 2011 4:12 PM >> To: softwires@ietf.org; behave@ietf.org >> Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite >>=20 >> Hello, >>=20 >> we submitted a new draft detailing our implementation of >> Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT) >>=20 >> http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 >>=20 >> This is a based on our experience with port bucket/chunk allocation and >> deterministic NAPT44. In the draft we provide a comparison with other >> stateless/stateful methods floating around. >>=20 >> Thanks, >>=20 >> Reinaldo >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From haibin.song@huawei.com Sat Nov 5 19:24:38 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540DE21F84D8; Sat, 5 Nov 2011 19:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.929 X-Spam-Level: X-Spam-Status: No, score=-5.929 tagged_above=-999 required=5 tests=[AWL=0.670, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hiyfhgm4hZ14; Sat, 5 Nov 2011 19:24:37 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id AFA5E21F84D7; Sat, 5 Nov 2011 19:24:37 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU70009OW0QDQ@szxga03-in.huawei.com>; Sun, 06 Nov 2011 10:24:26 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU700GTZW0Q0Z@szxga03-in.huawei.com>; Sun, 06 Nov 2011 10:24:26 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW46618; Sun, 06 Nov 2011 10:24:23 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 06 Nov 2011 10:24:23 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.229]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Sun, 06 Nov 2011 10:24:17 +0800 Date: Sun, 06 Nov 2011 02:17:47 +0000 From: Songhaibin X-Originating-IP: [172.24.2.40] To: "draft-ietf-behave-nat64-learn--analysis@tools.ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01 Thread-index: AcycJAiE5xn8o8YCQLGMfwsTYRl/TA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 07 Nov 2011 07:53:48 -0800 Cc: Behave WG , "tsv-ads@ietf.org" , TSV Dir Subject: [BEHAVE] tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 02:24:38 -0000 Hello, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. SUMMARY This draft is basically ready for publication, but has nits that should be fixed before publication. One comment: In section 5 (Conclusion), it compares DHCP/RA like solutions to DNS like solutions, and gives the recommendation of using DNS method, but without comparing that with STUN like methods. Is it possible to add it or people think there is obvious reason (DNS is better than STUN)? Another minor comment: In section 4.6.1 , [I-D.boucadair-dhcpv6-shared-address-option] also support NAT64 prefix allocation for building IPv4-embedded IPv6 address using DHCPv6 option. And this should be mentioned in the document. BR, -Haibin From ibc@aliax.net Sun Nov 6 08:45:23 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7438B21F8514; Sun, 6 Nov 2011 08:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nM9kQrsNZM4d; Sun, 6 Nov 2011 08:45:23 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE02C21F8509; Sun, 6 Nov 2011 08:45:22 -0800 (PST) Received: by vcbfl11 with SMTP id fl11so3849591vcb.31 for ; Sun, 06 Nov 2011 08:45:22 -0800 (PST) Received: by 10.220.65.16 with SMTP id g16mr1729414vci.68.1320597922063; Sun, 06 Nov 2011 08:45:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Sun, 6 Nov 2011 08:45:01 -0800 (PST) In-Reply-To: <4EB6B904.8050607@alvestrand.no> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <01O823CUB1SG00XBUL@mauve.mrochek.com> <4EB6B904.8050607@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 6 Nov 2011 17:45:01 +0100 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 07 Nov 2011 07:54:25 -0800 Cc: Keith Moore , "rtcweb@ietf.org" , Ned Freed , Keith Moore , Behave WG Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 16:45:23 -0000 2011/11/6 Harald Alvestrand : > I was thinking > > =C2=A0 turn://@?proto=3D > > but thought that this was going too far into details. Is not more appropriate to use "transport" rather than "proto"? --=20 I=C3=B1aki Baz Castillo From cb.list6@gmail.com Mon Nov 7 08:05:28 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8429421F8C47; Mon, 7 Nov 2011 08:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Kd3wDctzP14; Mon, 7 Nov 2011 08:05:24 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 121FE21F8BF4; Mon, 7 Nov 2011 08:05:23 -0800 (PST) Received: by qadc10 with SMTP id c10so4518882qad.31 for ; Mon, 07 Nov 2011 08:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cWHFR0iTX0IiZZdrbMu4zRzAgSkyCrNtepLccfp7SLY=; b=E5+gh0aG1RBE9zEvx+nlj0kghpfzy0s13FbtyTMYHDvMuQbeDwyFO7/v6v9yTDCbCd iO5stRpmvrHx7qfxAZ6e6TK++gcD60/NaZNtmxJ7td1rlxXW/sgxLBlE/quZ9yHG0ZQp NpqU9Po7plDmHZpsDjNuWfR+Nh0ckkBbV9Fi8= MIME-Version: 1.0 Received: by 10.50.36.168 with SMTP id r8mr46351463igj.49.1320681920956; Mon, 07 Nov 2011 08:05:20 -0800 (PST) Received: by 10.142.230.8 with HTTP; Mon, 7 Nov 2011 08:05:20 -0800 (PST) Received: by 10.142.230.8 with HTTP; Mon, 7 Nov 2011 08:05:20 -0800 (PST) In-Reply-To: <9328FE85-AE27-4F52-832D-5D7890DFDB48@juniper.net> References: <2073A6C5467C99478898544C6EBA3F4602BD2809D2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D671B85F60E@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9328FE85-AE27-4F52-832D-5D7890DFDB48@juniper.net> Date: Mon, 7 Nov 2011 08:05:20 -0800 Message-ID: From: Cameron Byrne To: Alain Durand Content-Type: multipart/alternative; boundary=14dae9340a25c2894a04b1273831 Cc: "softwires@ietf.org" , "Poscic, Kristian \(Kristian\)" , "Henderickx, Wim \(Wim\)" , "behave@ietf.org" Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 16:05:28 -0000 --14dae9340a25c2894a04b1273831 Content-Type: text/plain; charset=ISO-8859-1 On Nov 7, 2011 6:58 AM, "Alain Durand" wrote: > > > On Nov 4, 2011, at 2:21 AM, Henderickx, Wim (Wim) wrote: > > > Reinaldo, > > > > What happens if a customer wants to get more ports than the CPE owns? > > Similar to the other stateless proposals such a 4rd or divi, there is no provision to dynamically extend that range allocated by the ISP. > The consensus that was expressed a number of time in the wg is that if you need this flexibility, > a stateless solution is the wrong approach, you'd be be better of with a stateful solution. > > > > How would PCP operate with this model? > > This is an interesting question... This should make the life of the PCP server rather easy, as there will be no state to keep there too. > Interesting indeed, no pcp and no alg. So for stateless solutions anything that falls out of your static cgn allocation will not work? Like sip/rtp? Multiplayer games? Ftp? Rtsp? Pptp? Ipsec? ... Sorry if I missed something obvious for how these are enabled. Cb > Alain. > > > > > > > > > Cheers, > > Wim > > > > -----Original Message----- > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Reinaldo Penno > > Sent: vrijdag 4 november 2011 1:33 > > To: Poscic, Kristian (Kristian); softwires@ietf.org; behave@ietf.org > > Subject: Re: [Softwires] [BEHAVE] Stateless Deterministic NAPT/DS-Lite > > > > Hello Kristian, > > > > comments inline. > > > > > > On 11/3/11 4:38 PM, "Poscic, Kristian (Kristian)" > > wrote: > > > >> Just to make sure I understand this. > >> > >> Deterministic (statefull) NAT is deterministically translating inside IP to > >> outside IP + port range (take NAT44 case). > > > > Yes. > > > >> > >> Deterministic stateLESS NAT is deterministically translating inside IP + > >> inside_src_port to outside IP + outside_src_port. > >> No states are required since the incoming traffic in the downstream direction > >> (outside IP +port) can be deterministically translated to inside IP+port. > >> Any incoming traffic from outside will be mapped to something (predictable) on > >> the inside even though there may be no traffic initiated from the inside. > > > > Correct, no need for previous outbound packet. Subscriber gets port > > forwarding naturally as a consequence. > > > >> > >> CPE still needs statefull NAT. > >> > >> Is this correct? > > > > Yes. > > > >> Thanks, > >> Kris > >> > >> > >> -----Original Message----- > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of > >> Reinaldo Penno > >> Sent: Tuesday, November 01, 2011 4:12 PM > >> To: softwires@ietf.org; behave@ietf.org > >> Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite > >> > >> Hello, > >> > >> we submitted a new draft detailing our implementation of > >> Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT) > >> > >> http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 > >> > >> This is a based on our experience with port bucket/chunk allocation and > >> deterministic NAPT44. In the draft we provide a comparison with other > >> stateless/stateful methods floating around. > >> > >> Thanks, > >> > >> Reinaldo > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --14dae9340a25c2894a04b1273831 Content-Type: text/html; charset=ISO-8859-1


On Nov 7, 2011 6:58 AM, "Alain Durand" <adurand@juniper.net> wrote:
>
>
> On Nov 4, 2011, at 2:21 AM, Henderickx, Wim (Wim) wrote:
>
> > Reinaldo,
> >
> > What happens if a customer wants to get more ports than the CPE owns?
>
> Similar to the other stateless proposals such a 4rd or divi, there is no provision to dynamically extend that range allocated by the ISP.
> The consensus that was expressed a number of time in the wg is that if you need this flexibility,
> a stateless solution is the wrong approach, you'd be be better of with a stateful solution.
>
>
> > How would PCP operate with this model?
>
> This is an interesting question... This should make the life of the PCP server rather easy, as there will be no state to keep there too.
>

Interesting indeed, no pcp and no alg.

So for stateless solutions anything that falls out of your static cgn allocation will not work? Like sip/rtp? Multiplayer games? Ftp? Rtsp? Pptp? Ipsec? ...

Sorry if I missed something obvious for how these are enabled.

Cb

> Alain.
>
>
>
>
>
> >
> > Cheers,
> > Wim
> >
> > -----Original Message-----
> > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Reinaldo Penno
> > Sent: vrijdag 4 november 2011 1:33
> > To: Poscic, Kristian (Kristian); softwires@ietf.org; behave@ietf.org
> > Subject: Re: [Softwires] [BEHAVE] Stateless Deterministic NAPT/DS-Lite
> >
> > Hello Kristian,
> >
> > comments inline.
> >
> >
> > On 11/3/11 4:38 PM, "Poscic, Kristian (Kristian)"
> > <kristian.poscic@alcatel-lucent.com> wrote:
> >
> >> Just to make sure I understand this.
> >>
> >> Deterministic (statefull) NAT is deterministically translating inside IP to
> >> outside IP + port range (take NAT44 case).
> >
> > Yes.
> >
> >>
> >> Deterministic stateLESS NAT is deterministically translating inside IP +
> >> inside_src_port to outside IP + outside_src_port.
> >> No states are required since the incoming traffic in the downstream direction
> >> (outside IP +port) can be deterministically translated to inside IP+port.
> >> Any incoming traffic from outside will be mapped to something (predictable) on
> >> the inside even though there may be no traffic initiated from the inside.
> >
> > Correct, no need for previous outbound packet. Subscriber gets port
> > forwarding naturally as a consequence.
> >
> >>
> >> CPE still needs statefull NAT.
> >>
> >> Is this correct?
> >
> > Yes.
> >
> >> Thanks,
> >> Kris
> >>
> >>
> >> -----Original Message-----
> >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of
> >> Reinaldo Penno
> >> Sent: Tuesday, November 01, 2011 4:12 PM
> >> To: softwires@ietf.org; behave@ietf.org
> >> Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite
> >>
> >> Hello,
> >>
> >> we submitted a new draft detailing our implementation of
> >> Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT)
> >>
> >> http://tools.ietf.org/html/draft-penno-softwire-sdnat-01
> >>
> >> This is a based on our experience with port bucket/chunk allocation and
> >> deterministic NAPT44. In the draft we provide a comparison with other
> >> stateless/stateful methods floating around.
> >>
> >> Thanks,
> >>
> >> Reinaldo
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Behave mailing list
> >> Behave@ietf.org
> >> https://www.ietf.org/mailman/listinfo/behave
> >
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

--14dae9340a25c2894a04b1273831-- From cb.list6@gmail.com Mon Nov 7 09:11:16 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB7B21F8548; Mon, 7 Nov 2011 09:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.984 X-Spam-Level: X-Spam-Status: No, score=-2.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofcBVkoyTolK; Mon, 7 Nov 2011 09:11:15 -0800 (PST) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id B130B21F8B49; Mon, 7 Nov 2011 09:11:15 -0800 (PST) Received: by pzk4 with SMTP id 4so6682174pzk.9 for ; Mon, 07 Nov 2011 09:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xFu8XJWnyh0YZjmqPsvA3rUbD1/1JYzZy7o3LV9xDnM=; b=WdzdG8il8bd2NRWFYLEnhESvAMIH2FoGE41QycBcpVoT8Nrjn1/v19js6JKuDW8zZK GXNOVsOUKGYXDbhScQLz/0IyV2Sl9fZkoNn3YWORLPkvP+h7Pd0MHvg3OvV+k6Ezho77 D/37vWAnJNsmrfQ4Hr294zLJkcCzRbGmvJPqY= MIME-Version: 1.0 Received: by 10.68.47.4 with SMTP id z4mr487400pbm.39.1320685874162; Mon, 07 Nov 2011 09:11:14 -0800 (PST) Received: by 10.142.230.8 with HTTP; Mon, 7 Nov 2011 09:11:14 -0800 (PST) In-Reply-To: References: <2073A6C5467C99478898544C6EBA3F4602BD2809D2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D671B85F60E@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9328FE85-AE27-4F52-832D-5D7890DFDB48@juniper.net> Date: Mon, 7 Nov 2011 09:11:14 -0800 Message-ID: From: Cameron Byrne To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org" , "Poscic, Kristian \(Kristian\)" , "Henderickx, Wim \(Wim\)" , "behave@ietf.org" Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 17:11:16 -0000 On Mon, Nov 7, 2011 at 8:05 AM, Cameron Byrne wrote: > > On Nov 7, 2011 6:58 AM, "Alain Durand" wrote: >> >> >> On Nov 4, 2011, at 2:21 AM, Henderickx, Wim (Wim) wrote: >> >> > Reinaldo, >> > >> > What happens if a customer wants to get more ports than the CPE owns? >> >> Similar to the other stateless proposals such a 4rd or divi, there is no >> provision to dynamically extend that range allocated by the ISP. >> The consensus that was expressed a number of time in the wg is that if you >> need this flexibility, >> a stateless solution is the wrong approach, you'd be be better of with a >> stateful solution. >> >> >> > How would PCP operate with this model? >> >> This is an interesting question... This should make the life of the PCP >> server rather easy, as there will be no state to keep there too. >> > > Interesting indeed, no pcp and no alg. > > So for stateless solutions anything that falls out of your static cgn > allocation will not work? Like sip/rtp? Multiplayer games? Ftp? Rtsp? Pptp? > Ipsec? ... > > Sorry if I missed something obvious for how these are enabled. > > Cb Ok, i think i figured this one out, the SD-CPE will force the ports into the range supported on the CGN. From adurand@juniper.net Mon Nov 7 09:47:34 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452E511E8085; Mon, 7 Nov 2011 09:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJoWyuOWkOvT; Mon, 7 Nov 2011 09:47:33 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id ADA6711E8080; Mon, 7 Nov 2011 09:47:32 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Mon, 07 Nov 2011 09:47:33 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 7 Nov 2011 09:45:53 -0800 From: Alain Durand To: Cameron Byrne Date: Mon, 7 Nov 2011 09:45:51 -0800 Thread-Topic: [BEHAVE] Stateless Deterministic NAPT/DS-Lite Thread-Index: AcyddRfz+lGtn9LJRBK9y2Xe2qBllA== Message-ID: <25057BCC-DBC7-479E-85BC-1FA1760C2563@juniper.net> References: <2073A6C5467C99478898544C6EBA3F4602BD2809D2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D671B85F60E@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9328FE85-AE27-4F52-832D-5D7890DFDB48@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "Poscic, Kristian \(Kristian\)" , "Henderickx, Wim \(Wim\)" , "behave@ietf.org" Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 17:47:34 -0000 On Nov 7, 2011, at 11:05 AM, Cameron Byrne wrote: > > How would PCP operate with this model? > > This is an interesting question... This should make the life of the PCP s= erver rather easy, as there will be no state to keep there too. > Interesting indeed, no pcp and no alg PCP stil works. It is easier to implement. So for stateless solutions anything that falls out of your static cgn alloc= ation will not work? Like sip/rtp? Multiplayer games? Ftp? Rtsp? Pptp? Ipse= c? ... Sorry if I missed something obvious for how these are enabled. If those apps rely on listening on a well known port, they will fail with a= ny address/port sharing solution, stateful or stateless. If not, they negotiate ports with PCP or other methods before advertising i= t with a rendez-vous server. This is independent from stateful vs stateless= . Alain. From dwing@cisco.com Mon Nov 7 12:11:17 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FCE21F84B9 for ; Mon, 7 Nov 2011 12:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JCRNI-E2PV5 for ; Mon, 7 Nov 2011 12:10:56 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0E48121F847C for ; Mon, 7 Nov 2011 12:10:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=7566; q=dns/txt; s=iport; t=1320696656; x=1321906256; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=aB1xGdqU9kdKK5hvAC+VYO5EvLh9n907nxHOk12WBY4=; b=WcKQTPhE69IekgkgWSGL5LfWxiIJrKgLGE8vRQIKkyGbKq5/8M/nO2Db uiZnrIBCzGFqHJWeeBNl9xyC5yr2l/LO2Qdru8mBMe4QrLG6N7aHL2481 y33sAV+JRYLpufbk/EtvTyIL7fjyWiGJvyMqAl9kPjcIiBp7F/y4/ZcA4 U=; X-IronPort-AV: E=Sophos;i="4.69,471,1315180800"; d="scan'208";a="12786919" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 07 Nov 2011 20:10:55 +0000 Received: from dwingWS ([128.107.106.204]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA7KAsQS024902; Mon, 7 Nov 2011 20:10:54 GMT From: "Dan Wing" To: "'Brian E Carpenter'" References: <4EAF0384.1050002@gmail.com> <1be201cc98b3$249d7a90$6dd86fb0$@com> <4EB6EBEB.2010600@gmail.com> In-Reply-To: <4EB6EBEB.2010600@gmail.com> Date: Mon, 7 Nov 2011 12:10:54 -0800 Message-ID: <02f701cc9d89$5ad65ca0$108315e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcycwXakQnQimwNHRKSgyJv/vtDwYgAx1oCw Content-Language: en-us Cc: 'Prashanth Patil' , behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 20:11:19 -0000 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Sunday, November 06, 2011 12:20 PM > To: Dan Wing > Cc: 'Prashanth Patil'; behave@ietf.org > Subject: Re: [BEHAVE] I-D Action: = draft-wing-behave-dhcpv6-reconfigure- > 00.txt >=20 > On 2011-11-02 05:27, Dan Wing wrote: > >> -----Original Message----- > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >> Behalf Of Brian E Carpenter > >> Sent: Monday, October 31, 2011 1:22 PM > >> To: Prashanth Patil > >> Cc: behave@ietf.org > >> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6- > reconfigure- > >> 00.txt > >> > >> I don't get it. If a host is dual stacked it can be configured with > >> any DNS server, as long as it is not a DNS64. If you can have a > >> DNS64 directly visible, and a v4-only DNS server directly visible, > >> you are on a dual stack network, so you can also have a dual stack > >> DNS server directly visible. > > > > It is anticipated that a network will have a mix of IPv4-only, > > IPv6-only, and dual-stack hosts. The hosts don't know if they > > need a 'normal' DNS server or a DNS64, nor do we have a way > > to tell them the difference. >=20 > Indeed not, it is for the DHCPv6 server to ensure that the IPv6-only > hosts are pointed to the abnormal DNS server (i.e. the DNS64 server). > I'm left very uncomfortable by this kludge. Forcing dual-stack hosts > to resolve DNS via IPv4 seems backwards. Our proposal does not force dual-stack hosts to resolve DNS using IPv4 transport (DNS-over-IPv4). > Also, how will this help on a network that is using RFC 6106? > DHCPv6 isn't mandatory afaik. The RA-versus-DHCPv6 controversy is not unique to this idea, of course. Let's see if the idea has merit; if it does, we can describe how to provide similar functionality using unicast RA. -d > Brian >=20 > > > > This I-D attempts to provide a solution to that problem of a > > network with a mix of hosts that need to be configured with a > > 'normal' DNS server and DNS64 server. We believe the underlying > > idea (to "poke" a host to tell it something changed on the > > network) appears to have other applicability beyond the DNS/DNS64 > > use-case, as well. > > > > -d > > > > > >> Regards > >> Brian Carpenter > >> > >> On 2011-11-01 05:05, Prashanth Patil wrote: > >>> Hi Brian, > >>> The idea behind the proposal is to provision a means by which > traffic > >> is > >>> sent using IPv4 and not through the IPv6/IPv4 translator. The > >> advantage > >>> being that if NAT44 and NAT64 are deployed on the same network, it > is > >>> preferable to use NAT44 over NAT64 because of scale, performance > and > >>> application incompatibility issues (e.g., FTP) [RFC6384]. > >>> A "normal" DNS server does not have DNS64 capability. The IPv4- > mapped > >>> address for this "normal" server ensures that it can be reached > only > >> by > >>> IPv4=C5=A1. So if a host is IPv4-only, it will send a DNS query to = the > >> "normal" > >>> server just to get the A records. If the host is dual-stack it = will > >> also > >>> send a DNS query to the "normal" server to get both A and AAAA > >> records. If > >>> the destination address is an IPv4 address, dual-stack host just > >> gets A > >>> records but not synthesized AAAA records. So this technique will > >> ensure that > >>> IPv4 is preferred over the IPv6/IPv4 translator prefix and also > gives > >> native > >>> IPv6 higher precedence than IPv4. > >>> If the host happens to be IPv6 only, then it cannot reach the > >> "normal" > >>> server because it has IPv4-mapped prefix as explained previously. > So > >> IPv6 > >>> only host can only reach DNS64 server. So this host will send the > DNS > >> query > >>> to DNS64 to get AAAA records. Based on the destination address the > >> host will > >>> get IPv4-embedded IPv6 address or just the global IPv6 address. > >>> > >>> =C5=A1Note: From RFC 6052 > >>> =C2=B3When presented with the IPv4-mapped prefix, current versions = of > >> Windows and > >>> Mac OS generate IPv4 packets, but will not send IPv6 = packets.=C2=B2 > >>> > >>> -Prashanth > >>> > >>> On 22/10/11 6:20 AM, Brian E Carpenter wrote: > >>>> I have a basic question. Why does this draft define a 'normal' > >>>> DNS server as one having an IPv4-mapped IPv6 address? > >>>> > >>>> That seems like a completely *abnormal* DNS server for a dual > >>>> stack host. A dual stack host should normally have a DNS server > >>>> with a regular IPv6 address that will return both A and AAAA > >>>> records if they exist. Normally the server will be dual stacked > >>>> anyway, and will return exactly the same response whether the > >>>> query arrives via v4 or v6. > >>>> > >>>> A DNS server which only has an IPv4 address will also return > >>>> A and AAAA records if they exist, so there is absolutely no > >>>> difference as far as the dual stack host is concerned anyway. > >>>> So what is the point in using the IPv4-mapped address? > >>>> > >>>> Regards > >>>> Brian > >>>> > >>>> On 2011-10-18 11:17, internet-drafts@ietf.org wrote: > >>>>> A New Internet-Draft is available from the on-line Internet- > Drafts > >>>>> directories. > >>>>> > >>>>> Title : DHCPv6 Dynamic Re-Configuration > >>>>> Author(s) : Dan Wing > >>>>> Tirumaleswar Reddy > >>>>> Prashanth Patil > >>>>> Filename : = draft-wing-behave-dhcpv6-reconfigure-00.txt > >>>>> Pages : 10 > >>>>> Date : 2011-10-17 > >>>>> > >>>>> Some networks are expected to support IPv4-only, dual-stack, > >> and > >>>>> IPV6-only hosts at the same time. This makes prioritizing > the > >> DNS > >>>>> servers for hosts tricky due to a heterogeneous mix of > protocol > >>>>> stacks causing optimal behavior to occur only when the host > >> stack re- > >>>>> initializes. The networks infrastructure is usually well > >> equipped to > >>>>> be aware of single/dual-stack nature of hosts. This > >> specification > >>>>> extends DHCPv6 so that the DHCPv6 Relay Agent can = dynamically > >>>>> influence the priority of DNS servers provided to the host, > so > >> that > >>>>> the host can use the optimal DNS server for resolution. > >>>>> > >>>>> > >>>>> A URL for this Internet-Draft is: > >>>>> http://www.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- > >> reconfigure-00.t > >>>>> xt > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> This Internet-Draft can be retrieved at: > >>>>> ftp://ftp.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- > >> reconfigure-00.tx > >>>>> t > >>>>> _______________________________________________ > >>>>> 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 > >>>>> > >>>> _______________________________________________ > >>>> 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 rpenno@juniper.net Mon Nov 7 16:24:24 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A665221F8C2A; Mon, 7 Nov 2011 16:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YydgeWNaA7Gg; Mon, 7 Nov 2011 16:24:24 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id A66B521F8C26; Mon, 7 Nov 2011 16:24:22 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP; Mon, 07 Nov 2011 16:24:23 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 7 Nov 2011 16:24:02 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 7 Nov 2011 19:23:59 -0500 From: Reinaldo Penno To: Alain Durand , "Henderickx, Wim (Wim)" Date: Mon, 7 Nov 2011 19:23:58 -0500 Thread-Topic: [BEHAVE] Stateless Deterministic NAPT/DS-Lite Thread-Index: AcydXRnSNz2Uorw0Roe9tsMFV4SGdgAT5r6T Message-ID: In-Reply-To: <9328FE85-AE27-4F52-832D-5D7890DFDB48@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 00:24:24 -0000 On 11/7/11 6:54 AM, "Alain Durand" wrote: >=20 > On Nov 4, 2011, at 2:21 AM, Henderickx, Wim (Wim) wrote: >=20 >> Reinaldo, >>=20 >> What happens if a customer wants to get more ports than the CPE owns? >=20 > Similar to the other stateless proposals such a 4rd or divi, there is no > provision to dynamically extend that range allocated by the ISP. > The consensus that was expressed a number of time in the wg is that if yo= u > need this flexibility, > a stateless solution is the wrong approach, you'd be be better of with a > stateful solution. Actually Alain, we can do it. It is a trade-off between public IP usage efficiency and management. If CPE run out of ports that subscriber/private IP, if changing IP is not a= n option, is moved to another deterministic NAT pool with larger ranges. Everything is transparent. This assumes you have a two-tier NAT pool model (which is common), apart from that it is okay. >=20 >=20 >> How would PCP operate with this model? >=20 > This is an interesting question... This should make the life of the PCP s= erver > rather easy, as there will be no state to keep there too. >=20 > Alain. >=20 >=20 >=20 >=20 >=20 >>=20 >> Cheers, >> Wim >>=20 >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >> Behalf Of Reinaldo Penno >> Sent: vrijdag 4 november 2011 1:33 >> To: Poscic, Kristian (Kristian); softwires@ietf.org; behave@ietf.org >> Subject: Re: [Softwires] [BEHAVE] Stateless Deterministic NAPT/DS-Lite >>=20 >> Hello Kristian, >>=20 >> comments inline. >>=20 >>=20 >> On 11/3/11 4:38 PM, "Poscic, Kristian (Kristian)" >> wrote: >>=20 >>> Just to make sure I understand this. >>>=20 >>> Deterministic (statefull) NAT is deterministically translating inside I= P to >>> outside IP + port range (take NAT44 case). >>=20 >> Yes.=20 >>=20 >>>=20 >>> Deterministic stateLESS NAT is deterministically translating inside IP = + >>> inside_src_port to outside IP + outside_src_port. >>> No states are required since the incoming traffic in the downstream >>> direction >>> (outside IP +port) can be deterministically translated to inside IP+por= t. >>> Any incoming traffic from outside will be mapped to something (predicta= ble) >>> on >>> the inside even though there may be no traffic initiated from the insid= e. >>=20 >> Correct, no need for previous outbound packet. Subscriber gets port >> forwarding naturally as a consequence. >>=20 >>>=20 >>> CPE still needs statefull NAT. >>>=20 >>> Is this correct? >>=20 >> Yes. >>=20 >>> Thanks, >>> Kris >>>=20 >>>=20 >>> -----Original Message----- >>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behal= f Of >>> Reinaldo Penno >>> Sent: Tuesday, November 01, 2011 4:12 PM >>> To: softwires@ietf.org; behave@ietf.org >>> Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite >>>=20 >>> Hello, >>>=20 >>> we submitted a new draft detailing our implementation of >>> Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT) >>>=20 >>> http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 >>>=20 >>> This is a based on our experience with port bucket/chunk allocation and >>> deterministic NAPT44. In the draft we provide a comparison with other >>> stateless/stateful methods floating around. >>>=20 >>> Thanks, >>>=20 >>> Reinaldo >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >=20 From ietf-ipr@ietf.org Mon Nov 7 16:56:07 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5271F0C5D; Mon, 7 Nov 2011 16:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgQxy+6oYgJc; Mon, 7 Nov 2011 16:56:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15FE1F0C52; Mon, 7 Nov 2011 16:56:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: simon.perreault@viagenie.ca, ikuhei@nttv6.jp, miyakawa@nttv6.jp, a-nakagawa@jpix.ad.jp, ashida@itscom.ad.jp, X-Test-IDTracker: no Message-ID: <20111108005606.6341.96836.idtracker@ietfa.amsl.com> Date: Mon, 07 Nov 2011 16:56:06 -0800 Cc: behave@ietf.org, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com, ietfdbh@comcast.net, ipr-announce@ietf.org Subject: [BEHAVE] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-behave-lsn-requirements-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 00:56:07 -0000 Dear Simon Perreault, Ikuhei Yamagata, Shin Miyakawa, Akira Nakagawa, Hiroy= uki Ashida: An IPR disclosure that pertains to your Internet-Draft entitled "Common requirements for Carrier Grade NAT (CGN)" (draft-ietf-behave-lsn-requiremen= ts) was submitted to the IETF Secretariat on 2011-11-07 and has been posted on = the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1648/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-be= have- lsn-requirements-04.""); The IETF Secretariat From simon.perreault@viagenie.ca Mon Nov 7 17:07:16 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2018011E80B6 for ; Mon, 7 Nov 2011 17:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeKq9Qh04TVn for ; Mon, 7 Nov 2011 17:07:15 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7446011E8082 for ; Mon, 7 Nov 2011 17:07:15 -0800 (PST) Received: from banana.viagenie.ca (modemcable073.48-22-96.mc.videotron.ca [96.22.48.73]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CF00620D35 for ; Mon, 7 Nov 2011 20:06:44 -0500 (EST) Message-ID: <4EB880A4.7080407@viagenie.ca> Date: Mon, 07 Nov 2011 20:06:44 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 01:07:16 -0000 Hi, I read this draft and am a bit puzzled. It looks *very* similar to A+P. I see two enhancements (in academia we would call them "contributions"): - The CPE port range is learned dynamically. This is done by listening to ICMP errors. Question: how can the CPE differentiate between errors that mean "you're out of your allocated port set" and those that are normal errors that would have happened on a regular non-CGN connection? - There is a possibility of an arbitrary additional 1-to-1 mapping done on the CGN. If I understand correctly, these features could be considered as enhancements on top of A+P. Fundamentally this is still A+P. Did I get this right? Is there a fundamental difference I did not see? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From rpenno@juniper.net Mon Nov 7 20:42:02 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1B711E80F2 for ; Mon, 7 Nov 2011 20:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3I0SNJMZLDP for ; Mon, 7 Nov 2011 20:42:02 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id A2C0111E80EE for ; Mon, 7 Nov 2011 20:42:00 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Mon, 07 Nov 2011 20:42:01 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 7 Nov 2011 20:37:06 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 7 Nov 2011 23:37:05 -0500 From: Reinaldo Penno To: Simon Perreault , "behave@ietf.org" Date: Mon, 7 Nov 2011 23:37:03 -0500 Thread-Topic: [BEHAVE] Stateless Deterministic NAPT/DS-Lite Thread-Index: AcydssyFXxVbKWfGTCKMWtPimtAOEgAHUM8M Message-ID: In-Reply-To: <4EB880A4.7080407@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 04:42:02 -0000 Hi Simon, One of the fundamental aspects of A+P (http://tools.ietf.org/html/rfc6346) and variants discussed in softwires WG is the sharing of an IP address across CPEs, treating port number bits as extended IP address. That is not the case here. =20 Depending on configuration/policy each CPEs can get anything from a full IP to a port block of P ports, but there is still a unique WAN IP to each CPE. Thanks, Reinaldo On 11/7/11 5:06 PM, "Simon Perreault" wrote: > Hi, >=20 > I read this draft and am a bit puzzled. It looks *very* similar to A+P. I= see > two enhancements (in academia we would call them "contributions"): >=20 > - The CPE port range is learned dynamically. This is done by listening to= ICMP > errors. > Question: how can the CPE differentiate between errors that mean "you're = out > of > your allocated port set" and those that are normal errors that would have > happened on a regular non-CGN connection? >=20 > - There is a possibility of an arbitrary additional 1-to-1 mapping done o= n the > CGN. >=20 > If I understand correctly, these features could be considered as enhancem= ents > on > top of A+P. Fundamentally this is still A+P. >=20 > Did I get this right? Is there a fundamental difference I did not see? >=20 > Thanks, > Simon From jouni.nospam@gmail.com Tue Nov 8 01:52:07 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBF421F8B05; Tue, 8 Nov 2011 01:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11XEklUTCt3n; Tue, 8 Nov 2011 01:52:07 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 947D821F852E; Tue, 8 Nov 2011 01:52:03 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so275561bkb.31 for ; Tue, 08 Nov 2011 01:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=zsbvd7NOlSaqxgRgVIqqq5Rzaqf+sBhlPP8rKgjgzXQ=; b=TpP1PfQkudSKereMKnkQO+hdtcPRlI4kkfdLmedOHzwS5C/xP3J5Vm1XbgLgbElzzt 7oWSOYdtJdTGWZGq/UpYM6uTDAubwDTwzZ66ipqXr8XGtv8DlshATwHQ0tu3uLPZ27md ACWwj/2sFlbmx/fJT0r0S/GU9aFAuNEQzzjPg= Received: by 10.204.156.208 with SMTP id y16mr21215299bkw.72.1320745922482; Tue, 08 Nov 2011 01:52:02 -0800 (PST) Received: from a83-245-211-74.elisa-laajakaista.fi (a83-245-211-74.elisa-laajakaista.fi. [83.245.211.74]) by mx.google.com with ESMTPS id z13sm923685bkw.8.2011.11.08.01.51.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Nov 2011 01:52:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Tue, 8 Nov 2011 11:51:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Songhaibin X-Mailer: Apple Mail (2.1084) Cc: Behave WG , "tsv-ads@ietf.org" , "draft-ietf-behave-nat64-learn--analysis@tools.ietf.org" , TSV Dir Subject: Re: [BEHAVE] tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 09:52:07 -0000 Hi Haibin, Thank you for the review. See my comments inline. On Nov 6, 2011, at 4:17 AM, Songhaibin wrote: > Hello, >=20 > I've reviewed this document as part of the transport area = directorate's ongoing effort to review key IETF documents. These = comments were written primarily for the transport area directors, but = are copied to the document's authors for their information and to allow = them to address any issues raised. The authors should consider this = review together with any other last-call comments they receive. Please = always CC tsv-dir@ietf.org if you reply to or forward this review. >=20 > SUMMARY >=20 > This draft is basically ready for publication, but has nits that = should be fixed before publication. >=20 >=20 > One comment: >=20 > In section 5 (Conclusion), it compares DHCP/RA like solutions to DNS = like solutions, and gives the recommendation of using DNS method, but = without comparing that with STUN like methods. Is it possible to add it = or people think there is obvious reason (DNS is better than STUN)?=20 Good point. We should add some text along lines: "a host does not need = to implement STUN where as DNS is in practice required anyway. Also, = STUN protocol would be needed to changed on both host and network side = to support the discovery of NAT64". Would that work for you? >=20 > Another minor comment: >=20 > In section 4.6.1 , [I-D.boucadair-dhcpv6-shared-address-option] also = support NAT64 prefix allocation for building IPv4-embedded IPv6 address = using DHCPv6 option. And this should be mentioned in the document. Ok. Will add this. Thanks, Jouni >=20 >=20 > BR, > -Haibin > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Tue Nov 8 05:49:41 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2948721F8B5A for ; Tue, 8 Nov 2011 05:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAzQy7fsvaiz for ; Tue, 8 Nov 2011 05:49:40 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 806EC21F8B26 for ; Tue, 8 Nov 2011 05:49:40 -0800 (PST) Received: from banana.viagenie.ca (modemcable002.122-37-24.mc.videotron.ca [24.37.122.2]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BEDF021F3B; Tue, 8 Nov 2011 08:49:09 -0500 (EST) Message-ID: <4EB93354.3070907@viagenie.ca> Date: Tue, 08 Nov 2011 08:49:08 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 13:49:41 -0000 Reinaldo Penno wrote, on 11/07/2011 11:37 PM: > One of the fundamental aspects of A+P (http://tools.ietf.org/html/rfc6346) > and variants discussed in softwires WG is the sharing of an IP address > across CPEs, treating port number bits as extended IP address. That is not > the case here. > > Depending on configuration/policy each CPEs can get anything from a full IP > to a port block of P ports, but there is still a unique WAN IP to each CPE. In my understanding, in A+P, each CPE can also get anything from a full IP to a block of P ports, and there is also still a unique WAN IP to each CPE. No? I feel like I'm missing something obvious... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Nov 8 06:11:34 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2763921F8A57 for ; Tue, 8 Nov 2011 06:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZppamVtnJzZ for ; Tue, 8 Nov 2011 06:11:33 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D35821F8A55 for ; Tue, 8 Nov 2011 06:11:33 -0800 (PST) Received: from banana.viagenie.ca (modemcable002.122-37-24.mc.videotron.ca [24.37.122.2]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EA5F721F3B for ; Tue, 8 Nov 2011 09:11:02 -0500 (EST) Message-ID: <4EB93876.7090901@viagenie.ca> Date: Tue, 08 Nov 2011 09:11:02 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 14:11:34 -0000 jouni korhonen wrote, on 11/08/2011 04:51 AM: > Also, STUN > protocol would be needed to changed on both host and network side to support > the discovery of NAT64 Would it? Please explain why. If you send a STUN request using IPv6 transport and get a reply containing an IPv4 mapped address, you can be pretty sure that you're behind some kind of NAT64... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From adurand@juniper.net Tue Nov 8 07:19:51 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2760921F8D13 for ; Tue, 8 Nov 2011 07:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uAF-urHnL17 for ; Tue, 8 Nov 2011 07:19:50 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4F73F21F8D10 for ; Tue, 8 Nov 2011 07:19:50 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Tue, 08 Nov 2011 07:19:50 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 8 Nov 2011 07:13:57 -0800 From: Alain Durand To: Simon Perreault Date: Tue, 8 Nov 2011 07:13:56 -0800 Thread-Topic: [BEHAVE] Stateless Deterministic NAPT/DS-Lite Thread-Index: AcyeKQj17t4x8WkSQHyz0zDHbQBiAw== Message-ID: <28FCCD4E-FEC6-481A-B4C9-F2F5F8178E74@juniper.net> References: <4EB93354.3070907@viagenie.ca> In-Reply-To: <4EB93354.3070907@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] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 15:19:51 -0000 Simon: In A+P, the CPE must "learn" its external address and port one way or anot= her and do the translation accordingly. In SD-NAT, the CPE does not need to do that. It just translate using the WA= N (or B4) IP address. Alain. On Nov 8, 2011, at 8:49 AM, Simon Perreault wrote: > Reinaldo Penno wrote, on 11/07/2011 11:37 PM: >> One of the fundamental aspects of A+P (http://tools.ietf.org/html/rfc634= 6) >> and variants discussed in softwires WG is the sharing of an IP address >> across CPEs, treating port number bits as extended IP address. That is n= ot >> the case here. >>=20 >> Depending on configuration/policy each CPEs can get anything from a full= IP >> to a port block of P ports, but there is still a unique WAN IP to each C= PE. >=20 > In my understanding, in A+P, each CPE can also get anything from a full I= P to a > block of P ports, and there is also still a unique WAN IP to each CPE. No= ? >=20 > I feel like I'm missing something obvious... >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Tue Nov 8 07:22:14 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16B021F8D1C for ; Tue, 8 Nov 2011 07:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3Ej0j71bxjI for ; Tue, 8 Nov 2011 07:22:14 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 133DA21F85DB for ; Tue, 8 Nov 2011 07:22:14 -0800 (PST) Received: from banana.viagenie.ca (modemcable002.122-37-24.mc.videotron.ca [24.37.122.2]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6128D21100; Tue, 8 Nov 2011 10:21:43 -0500 (EST) Message-ID: <4EB94906.10107@viagenie.ca> Date: Tue, 08 Nov 2011 10:21:42 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Alain Durand References: <4EB93354.3070907@viagenie.ca> <28FCCD4E-FEC6-481A-B4C9-F2F5F8178E74@juniper.net> In-Reply-To: <28FCCD4E-FEC6-481A-B4C9-F2F5F8178E74@juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 15:22:15 -0000 Alain Durand wrote, on 11/08/2011 10:13 AM: > In A+P, the CPE must "learn" its external address and port one way or another and do the translation accordingly. > In SD-NAT, the CPE does not need to do that. It just translate using the WAN (or B4) IP address. Got it, thanks! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Nov 8 10:26:05 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC1521F8B50 for ; Tue, 8 Nov 2011 10:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0TcGWBl29Ld for ; Tue, 8 Nov 2011 10:26:02 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id C857B21F8505 for ; Tue, 8 Nov 2011 10:26:02 -0800 (PST) Received: from banana.viagenie.ca (modemcable002.122-37-24.mc.videotron.ca [24.37.122.2]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DBC9020CF1; Tue, 8 Nov 2011 13:25:31 -0500 (EST) Message-ID: <4EB9741A.40800@viagenie.ca> Date: Tue, 08 Nov 2011 13:25:30 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: jouni korhonen References: <4EB93876.7090901@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 18:26:05 -0000 jouni korhonen wrote, on 11/08/2011 12:09 PM: >>> Also, STUN >>> protocol would be needed to changed on both host and network side to support >>> the discovery of NAT64 >> >> Would it? Please explain why. > > Because of the text few WG participants wanted us to included into the analysis when using STUN for NAT64 discovery. That resulted to the text below, which very much implies protocol work to me: > > After learning the IPv6 address of a STUN server the STUN client > sends a request to the STUN server containing new 'SENDING-TO' > attribute that tells to the server the IPv6 address the client sent > the request to. In a reply the server includes another new attribute > called 'RECEIVED-AS', which contains server's IP address the request > arrived on. After receiving the reply the client compares > 'SENDING-TO' and 'RECEIVED-AS' attributes to find out an NSP > candidate. Can you point me to the rationale for these additional parameters? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From jouni.nospam@gmail.com Tue Nov 8 11:07:34 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF2C1F0C55 for ; Tue, 8 Nov 2011 11:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2saZR0v8jXa for ; Tue, 8 Nov 2011 11:07:33 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 79CC11F0C43 for ; Tue, 8 Nov 2011 11:07:33 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so896111bkb.31 for ; Tue, 08 Nov 2011 11:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=OYfcdxpFU36kkjW1xv346H/dgYPjs5l4VlXDdLDzCdo=; b=tXYgW2BYJBsKRm7s2qonGFDpxyy0GfHUJ8t/4toPX1VeDr7avSAcdcz7AAxwpCO6YR GVafCJE318gHOEYPJImjBNZg5R3I577n4WWux/HtQAmNTC/AG8CnpzbMD6ku0aFT2WQd 7IGgfZWgNkTMVC1IzBmJmlz5VH2NaeRFWzPa8= Received: by 10.204.133.197 with SMTP id g5mr8214349bkt.43.1320779252531; Tue, 08 Nov 2011 11:07:32 -0800 (PST) Received: from [188.117.15.99] ([188.117.15.99]) by mx.google.com with ESMTPS id r12sm2446869bkw.5.2011.11.08.11.07.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Nov 2011 11:07:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4EB9741A.40800@viagenie.ca> Date: Tue, 8 Nov 2011 21:07:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB93876.7090901@viagenie.ca> <4EB9741A.40800@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1084) Cc: behave@ietf.org Subject: Re: [BEHAVE] tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 19:07:34 -0000 On Nov 8, 2011, at 8:25 PM, Simon Perreault wrote: > jouni korhonen wrote, on 11/08/2011 12:09 PM: >>>> Also, STUN >>>> protocol would be needed to changed on both host and network side = to support >>>> the discovery of NAT64 >>>=20 >>> Would it? Please explain why. >>=20 >> Because of the text few WG participants wanted us to included into = the analysis when using STUN for NAT64 discovery. That resulted to the = text below, which very much implies protocol work to me: >>=20 >> After learning the IPv6 address of a STUN server the STUN client >> sends a request to the STUN server containing new 'SENDING-TO' >> attribute that tells to the server the IPv6 address the client sent >> the request to. In a reply the server includes another new attribute >> called 'RECEIVED-AS', which contains server's IP address the request >> arrived on. After receiving the reply the client compares >> 'SENDING-TO' and 'RECEIVED-AS' attributes to find out an NSP >> candidate. >=20 > Can you point me to the rationale for these additional parameters? Ask Dan, Christian, Teemu and Med. - Jouni >=20 > Thanks, > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From brian.e.carpenter@gmail.com Tue Nov 8 17:58:33 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBBE21F8A55 for ; Tue, 8 Nov 2011 17:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYrADwEGDLte for ; Tue, 8 Nov 2011 17:58:32 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 165BB21F8997 for ; Tue, 8 Nov 2011 17:58:32 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so1141059vcb.31 for ; Tue, 08 Nov 2011 17:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=3VcDoeftBruwrL/9vYZUDAhpmULDYysVkTqsrsT2prc=; b=lb+EyPd1Dv8+ziAmAgiuCaGm6HaGJwNomo0Ws/Rj9h3WjuKOpNyjDVmuZRXYCIsVYD O0w1BS4K/1c8aLcy2FUom2G3cmTOB0zKGLBop9naeErLHJngRtAmqdIGdGLoF5CFCZz7 1wUBtODKe1YyaneMDjNSjLvWrFtnKQed0l6VU= Received: by 10.52.113.227 with SMTP id jb3mr790441vdb.15.1320803911549; Tue, 08 Nov 2011 17:58:31 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id p2sm5120370vdi.22.2011.11.08.17.58.27 (version=SSLv3 cipher=OTHER); Tue, 08 Nov 2011 17:58:30 -0800 (PST) Message-ID: <4EB9DE53.70805@gmail.com> Date: Wed, 09 Nov 2011 14:58:43 +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: <4EAF0384.1050002@gmail.com> <1be201cc98b3$249d7a90$6dd86fb0$@com> <4EB6EBEB.2010600@gmail.com> <02f701cc9d89$5ad65ca0$108315e0$@com> In-Reply-To: <02f701cc9d89$5ad65ca0$108315e0$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 'Prashanth Patil' , behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 01:58:33 -0000 Dan, > Our proposal does not force dual-stack hosts to resolve DNS using > IPv4 transport (DNS-over-IPv4). I must have misunderstood again. It seems to me that this is exactly the effect of the following process: 1. *IPv6-only transition to Dual-Stack* In case a host is IPv6-only to start off, it is provided a DNS64 Server. When transitioning to dual-stack, a IPv4 DNS Server is assigned as a consequence of obtaining an IPv4 Address. The DHCPv6 Relay Agent can detect this and send RELAY-RECONFIG message Section 4.1 to the DHCPv6 Server indicating that the host needs to be needs to be provided with "normal" DNS Server followed by DNS64 server. That would give it an IPv4-mapped address for DNS service, which it would= therefore access using native IPv4. Regards Brian On 2011-11-08 09:10, Dan Wing wrote: >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Sunday, November 06, 2011 12:20 PM >> To: Dan Wing >> Cc: 'Prashanth Patil'; behave@ietf.org >> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure= - >> 00.txt >> >> On 2011-11-02 05:27, Dan Wing wrote: >>>> -----Original Message----- >>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>>> Behalf Of Brian E Carpenter >>>> Sent: Monday, October 31, 2011 1:22 PM >>>> To: Prashanth Patil >>>> Cc: behave@ietf.org >>>> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6- >> reconfigure- >>>> 00.txt >>>> >>>> I don't get it. If a host is dual stacked it can be configured with >>>> any DNS server, as long as it is not a DNS64. If you can have a >>>> DNS64 directly visible, and a v4-only DNS server directly visible, >>>> you are on a dual stack network, so you can also have a dual stack >>>> DNS server directly visible. >>> It is anticipated that a network will have a mix of IPv4-only, >>> IPv6-only, and dual-stack hosts. The hosts don't know if they >>> need a 'normal' DNS server or a DNS64, nor do we have a way >>> to tell them the difference. >> Indeed not, it is for the DHCPv6 server to ensure that the IPv6-only >> hosts are pointed to the abnormal DNS server (i.e. the DNS64 server). >> I'm left very uncomfortable by this kludge. Forcing dual-stack hosts >> to resolve DNS via IPv4 seems backwards. >=20 > Our proposal does not force dual-stack hosts to resolve DNS using > IPv4 transport (DNS-over-IPv4). >=20 >> Also, how will this help on a network that is using RFC 6106? >> DHCPv6 isn't mandatory afaik. >=20 > The RA-versus-DHCPv6 controversy is not unique to this idea, > of course. >=20 > Let's see if the idea has merit; if it does, we can describe > how to provide similar functionality using unicast RA. >=20 > -d >=20 >=20 >> Brian >> >>> This I-D attempts to provide a solution to that problem of a >>> network with a mix of hosts that need to be configured with a >>> 'normal' DNS server and DNS64 server. We believe the underlying >>> idea (to "poke" a host to tell it something changed on the >>> network) appears to have other applicability beyond the DNS/DNS64 >>> use-case, as well. >>> >>> -d >>> >>> >>>> Regards >>>> Brian Carpenter >>>> >>>> On 2011-11-01 05:05, Prashanth Patil wrote: >>>>> Hi Brian, >>>>> The idea behind the proposal is to provision a means by which >> traffic >>>> is >>>>> sent using IPv4 and not through the IPv6/IPv4 translator. The >>>> advantage >>>>> being that if NAT44 and NAT64 are deployed on the same network, it >> is >>>>> preferable to use NAT44 over NAT64 because of scale, performance >> and >>>>> application incompatibility issues (e.g., FTP) [RFC6384]. >>>>> A "normal" DNS server does not have DNS64 capability. The IPv4- >> mapped >>>>> address for this "normal" server ensures that it can be reached >> only >>>> by >>>>> IPv4=C5=A1. So if a host is IPv4-only, it will send a DNS query to = the >>>> "normal" >>>>> server just to get the A records. If the host is dual-stack it will= >>>> also >>>>> send a DNS query to the "normal" server to get both A and AAAA >>>> records. If >>>>> the destination address is an IPv4 address, dual-stack host just >>>> gets A >>>>> records but not synthesized AAAA records. So this technique will >>>> ensure that >>>>> IPv4 is preferred over the IPv6/IPv4 translator prefix and also >> gives >>>> native >>>>> IPv6 higher precedence than IPv4. >>>>> If the host happens to be IPv6 only, then it cannot reach the >>>> "normal" >>>>> server because it has IPv4-mapped prefix as explained previously. >> So >>>> IPv6 >>>>> only host can only reach DNS64 server. So this host will send the >> DNS >>>> query >>>>> to DNS64 to get AAAA records. Based on the destination address the >>>> host will >>>>> get IPv4-embedded IPv6 address or just the global IPv6 address. >>>>> >>>>> =C5=A1Note: From RFC 6052 >>>>> =C2=B3When presented with the IPv4-mapped prefix, current versions = of >>>> Windows and >>>>> Mac OS generate IPv4 packets, but will not send IPv6 packets.=C2=B2= >>>>> >>>>> -Prashanth >>>>> >>>>> On 22/10/11 6:20 AM, Brian E Carpenter wrote: >>>>>> I have a basic question. Why does this draft define a 'normal' >>>>>> DNS server as one having an IPv4-mapped IPv6 address? >>>>>> >>>>>> That seems like a completely *abnormal* DNS server for a dual >>>>>> stack host. A dual stack host should normally have a DNS server >>>>>> with a regular IPv6 address that will return both A and AAAA >>>>>> records if they exist. Normally the server will be dual stacked >>>>>> anyway, and will return exactly the same response whether the >>>>>> query arrives via v4 or v6. >>>>>> >>>>>> A DNS server which only has an IPv4 address will also return >>>>>> A and AAAA records if they exist, so there is absolutely no >>>>>> difference as far as the dual stack host is concerned anyway. >>>>>> So what is the point in using the IPv4-mapped address? >>>>>> >>>>>> Regards >>>>>> Brian >>>>>> >>>>>> On 2011-10-18 11:17, internet-drafts@ietf.org wrote: >>>>>>> A New Internet-Draft is available from the on-line Internet- >> Drafts >>>>>>> directories. >>>>>>> >>>>>>> Title : DHCPv6 Dynamic Re-Configuration >>>>>>> Author(s) : Dan Wing >>>>>>> Tirumaleswar Reddy >>>>>>> Prashanth Patil >>>>>>> Filename : draft-wing-behave-dhcpv6-reconfigure-00.txt= >>>>>>> Pages : 10 >>>>>>> Date : 2011-10-17 >>>>>>> >>>>>>> Some networks are expected to support IPv4-only, dual-stack, >>>> and >>>>>>> IPV6-only hosts at the same time. This makes prioritizing >> the >>>> DNS >>>>>>> servers for hosts tricky due to a heterogeneous mix of >> protocol >>>>>>> stacks causing optimal behavior to occur only when the host >>>> stack re- >>>>>>> initializes. The networks infrastructure is usually well >>>> equipped to >>>>>>> be aware of single/dual-stack nature of hosts. This >>>> specification >>>>>>> extends DHCPv6 so that the DHCPv6 Relay Agent can dynamically= >>>>>>> influence the priority of DNS servers provided to the host, >> so >>>> that >>>>>>> the host can use the optimal DNS server for resolution. >>>>>>> >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> http://www.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- >>>> reconfigure-00.t >>>>>>> xt >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> This Internet-Draft can be retrieved at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- >>>> reconfigure-00.tx >>>>>>> t >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >=20 From brian.e.carpenter@gmail.com Tue Nov 8 18:13:40 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDF821F8A56 for ; Tue, 8 Nov 2011 18:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.489 X-Spam-Level: X-Spam-Status: No, score=-103.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zidNVlOnvUD for ; Tue, 8 Nov 2011 18:13:39 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A385A21F8A57 for ; Tue, 8 Nov 2011 18:13:39 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so1149855vcb.31 for ; Tue, 08 Nov 2011 18:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=cA0ZaztYPv4IxSlKb03ytOs7BVo+uaITmdK2veIONys=; b=gB5xd8sas4EJMogIm4GOB9fWVbiftpi+HRu78Xcmv4sEHcma30Jzy9hmUsI7zEH4xF KG7yI2H/qt33+fVO7GUyzxn/CR/L+bs8clpHhhrErWeO9arHq2mLDTLnNi7sWSvQwaCw a775XXaJeChLvI+B+x0BoOFjfdZBDf40DB/u0= Received: by 10.52.173.211 with SMTP id bm19mr598016vdc.115.1320804819099; Tue, 08 Nov 2011 18:13:39 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id p2sm5174742vdi.22.2011.11.08.18.13.37 (version=SSLv3 cipher=OTHER); Tue, 08 Nov 2011 18:13:38 -0800 (PST) Message-ID: <4EB9E1E0.1070501@gmail.com> Date: Wed, 09 Nov 2011 15:13:52 +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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] DNS64 detecting dual stack clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 02:13:40 -0000 Maybe this has been discussed before, but it seems to me that a DNS64 can figure out which clients are dual stack and act accordingly. * The DNS64 runs on a box which is dual stacked. In fact, it will contain a straight dual-stack DNS server as well as a DNS64. They schmooze. * The box has an ARP cache and an ND cache. * Whenever a new host appears in the ARP cache, the box checks the MAC address against the ND cache, and vice versa. * If there is a match, the host concerned is tagged as dual-stack and DNS64 synthesis is bypassed for all future queries. * Add some timeout/refresh logic to keep the information current. * The worst case is that one query is given a synthetic DNS64 response before the ARP entry is matched. Regards Brian Carpenter From dwing@cisco.com Tue Nov 8 19:10:00 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BE521F8494 for ; Tue, 8 Nov 2011 19:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.631 X-Spam-Level: X-Spam-Status: No, score=-105.631 tagged_above=-999 required=5 tests=[AWL=0.968, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaQrvj69kd5D for ; Tue, 8 Nov 2011 19:09:59 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0179011E80B6 for ; Tue, 8 Nov 2011 19:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=10482; q=dns/txt; s=iport; t=1320808199; x=1322017799; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=2rD5qw3xKWesuLOSSCgjubgwuYM4k7q+lhy+BN1ZNQA=; b=OsPeCNyY+CyFJMMiVcMLs2/ovOzRTzr3sBkVcGbx6CEnHONp3i8bOwr9 VYQaieczdXSRy1VjYJ47y+aIkwMFAfp38y/hLgC2LKLWGGrjhkcdcq9oU w1C4d6l6XOWkVZKNSoC5hUb/2Ujg24RSCaQIKF/zTLQG3kL7rcV5PVKOm M=; X-IronPort-AV: E=Sophos;i="4.69,481,1315180800"; d="scan'208";a="13102927" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 09 Nov 2011 03:09:53 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA939rqJ024167; Wed, 9 Nov 2011 03:09:53 GMT From: "Dan Wing" To: "'Brian E Carpenter'" References: <4EAF0384.1050002@gmail.com> <1be201cc98b3$249d7a90$6dd86fb0$@com> <4EB6EBEB.2010600@gmail.com> <02f701cc9d89$5ad65ca0$108315e0$@com> <4EB9DE53.70805@gmail.com> In-Reply-To: <4EB9DE53.70805@gmail.com> Date: Tue, 8 Nov 2011 19:09:53 -0800 Message-ID: <03bc01cc9e8d$0d27ef00$2777cd00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyegxXEZ7LD2VyOQvGubBHZvbdX/wACOEWQ Content-Language: en-us Cc: 'Prashanth Patil' , behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:10:00 -0000 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Tuesday, November 08, 2011 5:59 PM > To: Dan Wing > Cc: 'Prashanth Patil'; behave@ietf.org > Subject: Re: [BEHAVE] I-D Action: = draft-wing-behave-dhcpv6-reconfigure- > 00.txt >=20 > Dan, >=20 > > Our proposal does not force dual-stack hosts to resolve DNS using > > IPv4 transport (DNS-over-IPv4). >=20 > I must have misunderstood again. It seems to me that this is exactly > the effect of the following process: >=20 > 1. *IPv6-only transition to Dual-Stack* In case a host is = IPv6-only > to start off, it is provided a DNS64 Server. When = transitioning > to dual-stack, a IPv4 DNS Server is assigned as a consequence = of > obtaining an IPv4 Address. The DHCPv6 Relay Agent can detect > this and send RELAY-RECONFIG message Section 4.1 to the DHCPv6 > Server indicating that the host needs to be needs to be = provided > with "normal" DNS Server followed by DNS64 server. >=20 > That would give it an IPv4-mapped address for DNS service, which it > would therefore access using native IPv4. Ah, because we define: 'normal' DNS server : DNS server using an IPv4-mapped IPv6 address (that is, an IPv6 address starting with ::ffff:/96 IPv4-mapped prefix). Hosts can communicate with 'normal' DNS server only using IPv4 packets [RFC6052], section 4.2. Yes, agreed, that is how the text is written. This whole idea was built around "how can we improve draft-wing-behave-dns64-config", which did the IPv4-mapped address trick -- that trick just doesn't always work. So, until we can update the I-D, imagine that the definition of "normal DNS server" is "a DNS server that is not performing DNS64 functions". Said another way, "normal DNS server" is a normal DNS server that is found on nearly 100% of networks today that does not synthesize AAAA records. With that change, would you have an objection? But, back to your objection -- what's the problem with a dual-stack host sending its DNS queries over IPv4? The only issue I see is 1. it is impure 2. if IPv4 address sharing is on the path between the client and DNS server, the DNS queries will consume UDP and TCP ports.=20 Are there other objections to sending DNS queries over IPv4? -d > Regards > Brian >=20 > On 2011-11-08 09:10, Dan Wing wrote: > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: Sunday, November 06, 2011 12:20 PM > >> To: Dan Wing > >> Cc: 'Prashanth Patil'; behave@ietf.org > >> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6- > reconfigure- > >> 00.txt > >> > >> On 2011-11-02 05:27, Dan Wing wrote: > >>>> -----Original Message----- > >>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >>>> Behalf Of Brian E Carpenter > >>>> Sent: Monday, October 31, 2011 1:22 PM > >>>> To: Prashanth Patil > >>>> Cc: behave@ietf.org > >>>> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6- > >> reconfigure- > >>>> 00.txt > >>>> > >>>> I don't get it. If a host is dual stacked it can be configured > with > >>>> any DNS server, as long as it is not a DNS64. If you can have a > >>>> DNS64 directly visible, and a v4-only DNS server directly = visible, > >>>> you are on a dual stack network, so you can also have a dual = stack > >>>> DNS server directly visible. > >>> It is anticipated that a network will have a mix of IPv4-only, > >>> IPv6-only, and dual-stack hosts. The hosts don't know if they > >>> need a 'normal' DNS server or a DNS64, nor do we have a way > >>> to tell them the difference. > >> Indeed not, it is for the DHCPv6 server to ensure that the = IPv6-only > >> hosts are pointed to the abnormal DNS server (i.e. the DNS64 > server). > >> I'm left very uncomfortable by this kludge. Forcing dual-stack = hosts > >> to resolve DNS via IPv4 seems backwards. > > > > Our proposal does not force dual-stack hosts to resolve DNS using > > IPv4 transport (DNS-over-IPv4). > > > >> Also, how will this help on a network that is using RFC 6106? > >> DHCPv6 isn't mandatory afaik. > > > > The RA-versus-DHCPv6 controversy is not unique to this idea, > > of course. > > > > Let's see if the idea has merit; if it does, we can describe > > how to provide similar functionality using unicast RA. > > > > -d > > > > > >> Brian > >> > >>> This I-D attempts to provide a solution to that problem of a > >>> network with a mix of hosts that need to be configured with a > >>> 'normal' DNS server and DNS64 server. We believe the underlying > >>> idea (to "poke" a host to tell it something changed on the > >>> network) appears to have other applicability beyond the DNS/DNS64 > >>> use-case, as well. > >>> > >>> -d > >>> > >>> > >>>> Regards > >>>> Brian Carpenter > >>>> > >>>> On 2011-11-01 05:05, Prashanth Patil wrote: > >>>>> Hi Brian, > >>>>> The idea behind the proposal is to provision a means by which > >> traffic > >>>> is > >>>>> sent using IPv4 and not through the IPv6/IPv4 translator. The > >>>> advantage > >>>>> being that if NAT44 and NAT64 are deployed on the same network, > it > >> is > >>>>> preferable to use NAT44 over NAT64 because of scale, performance > >> and > >>>>> application incompatibility issues (e.g., FTP) [RFC6384]. > >>>>> A "normal" DNS server does not have DNS64 capability. The IPv4- > >> mapped > >>>>> address for this "normal" server ensures that it can be reached > >> only > >>>> by > >>>>> IPv4=C5=A1. So if a host is IPv4-only, it will send a DNS query = to the > >>>> "normal" > >>>>> server just to get the A records. If the host is dual-stack it > will > >>>> also > >>>>> send a DNS query to the "normal" server to get both A and AAAA > >>>> records. If > >>>>> the destination address is an IPv4 address, dual-stack host = just > >>>> gets A > >>>>> records but not synthesized AAAA records. So this technique will > >>>> ensure that > >>>>> IPv4 is preferred over the IPv6/IPv4 translator prefix and also > >> gives > >>>> native > >>>>> IPv6 higher precedence than IPv4. > >>>>> If the host happens to be IPv6 only, then it cannot reach the > >>>> "normal" > >>>>> server because it has IPv4-mapped prefix as explained = previously. > >> So > >>>> IPv6 > >>>>> only host can only reach DNS64 server. So this host will send = the > >> DNS > >>>> query > >>>>> to DNS64 to get AAAA records. Based on the destination address > the > >>>> host will > >>>>> get IPv4-embedded IPv6 address or just the global IPv6 address. > >>>>> > >>>>> =C5=A1Note: From RFC 6052 > >>>>> =C2=B3When presented with the IPv4-mapped prefix, current = versions of > >>>> Windows and > >>>>> Mac OS generate IPv4 packets, but will not send IPv6 = packets.=C2=B2 > >>>>> > >>>>> -Prashanth > >>>>> > >>>>> On 22/10/11 6:20 AM, Brian E Carpenter wrote: > >>>>>> I have a basic question. Why does this draft define a 'normal' > >>>>>> DNS server as one having an IPv4-mapped IPv6 address? > >>>>>> > >>>>>> That seems like a completely *abnormal* DNS server for a dual > >>>>>> stack host. A dual stack host should normally have a DNS server > >>>>>> with a regular IPv6 address that will return both A and AAAA > >>>>>> records if they exist. Normally the server will be dual stacked > >>>>>> anyway, and will return exactly the same response whether the > >>>>>> query arrives via v4 or v6. > >>>>>> > >>>>>> A DNS server which only has an IPv4 address will also return > >>>>>> A and AAAA records if they exist, so there is absolutely no > >>>>>> difference as far as the dual stack host is concerned anyway. > >>>>>> So what is the point in using the IPv4-mapped address? > >>>>>> > >>>>>> Regards > >>>>>> Brian > >>>>>> > >>>>>> On 2011-10-18 11:17, internet-drafts@ietf.org wrote: > >>>>>>> A New Internet-Draft is available from the on-line Internet- > >> Drafts > >>>>>>> directories. > >>>>>>> > >>>>>>> Title : DHCPv6 Dynamic Re-Configuration > >>>>>>> Author(s) : Dan Wing > >>>>>>> Tirumaleswar Reddy > >>>>>>> Prashanth Patil > >>>>>>> Filename : draft-wing-behave-dhcpv6-reconfigure- > 00.txt > >>>>>>> Pages : 10 > >>>>>>> Date : 2011-10-17 > >>>>>>> > >>>>>>> Some networks are expected to support IPv4-only, dual- > stack, > >>>> and > >>>>>>> IPV6-only hosts at the same time. This makes prioritizing > >> the > >>>> DNS > >>>>>>> servers for hosts tricky due to a heterogeneous mix of > >> protocol > >>>>>>> stacks causing optimal behavior to occur only when the = host > >>>> stack re- > >>>>>>> initializes. The networks infrastructure is usually well > >>>> equipped to > >>>>>>> be aware of single/dual-stack nature of hosts. This > >>>> specification > >>>>>>> extends DHCPv6 so that the DHCPv6 Relay Agent can > dynamically > >>>>>>> influence the priority of DNS servers provided to the = host, > >> so > >>>> that > >>>>>>> the host can use the optimal DNS server for resolution. > >>>>>>> > >>>>>>> > >>>>>>> A URL for this Internet-Draft is: > >>>>>>> http://www.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- > >>>> reconfigure-00.t > >>>>>>> xt > >>>>>>> > >>>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>>> > >>>>>>> This Internet-Draft can be retrieved at: > >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- > >>>> reconfigure-00.tx > >>>>>>> t > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 ajs@anvilwalrusden.com Tue Nov 8 19:30:07 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A92B1F0C50 for ; Tue, 8 Nov 2011 19:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUhGe3TYdIw6 for ; Tue, 8 Nov 2011 19:30:06 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D91751F0C4D for ; Tue, 8 Nov 2011 19:30:06 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id ED1551ECB41D for ; Wed, 9 Nov 2011 03:29:53 +0000 (UTC) Date: Tue, 8 Nov 2011 22:30:03 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20111109033003.GL78156@shinkuro.com> References: <4EB9E1E0.1070501@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB9E1E0.1070501@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] DNS64 detecting dual stack clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:30:07 -0000 This is not to pick on Brian. But he provides the occasion. On Wed, Nov 09, 2011 at 03:13:52PM +1300, Brian E Carpenter wrote: > Maybe this has been discussed before, but it seems to me that a DNS64 can > figure out which clients are dual stack and act accordingly. What is the "act accordingly" that is the right thing here? I am sick unto death of suggestions to make DNS64+NAT64 work more reliably. It is a nasty, 80% solution hack. I cannot speak for anyone else involved with it, but to me it was _always_ supposed to be a nasty hack -- useful as a kind of field bandage for the most egregious problems caused by the fact that there was no real IPv4-IPv6 upgrade path. We live in a world with no more IPv4 network addresses and little IPv6 penetration; and also one where "the Internet", for many people, means "what I get in my browser." I have taken as my motto a sort of Homer Simpson one: "Aim low." If we can mostly fix things most of the time for the most common case, it's useful. It's still a nasty hack, but it's useful for now. In my opinion, "act accordingly" is to get out one of those muzzle-loading-cannon-on-scissors that is so popular in Warner Bros cartoons, and shoot it at the network administrator who configured some poor slob's computer with a dual stack and a NAT64. Any other case -- like solving the case where I somehow accidentally stumble onto a NAT64 network with an unmolested IPv4 connection that nobody knows about -- sounds to me like an optimization that shouldn't be considered. If the complaint is, "Yes, but then people will use NAT when they don't have to," I express my doubts. An infinitesimally small number of people use unmolested, NAT-free IPv4 today. Those people already know how to cope with IPv6 and how to avoid sludge like NAT64. Everybody else just has a crappy choice of NATs to make. If the argument is instead that we can make protocols with embedded IPv4 literals in them work marginally better this way, then I suggest the additional complications are not worth making for protocols that are wrong in their conception to begin with. Please, let us not fix something that is broken exactly as much as it ought to be. The pig is wearing enough lipstick. We should put away the cosmetics now. A -- Andrew Sullivan ajs@anvilwalrusden.com From brian.e.carpenter@gmail.com Tue Nov 8 19:33:30 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2EA21F88A0 for ; Tue, 8 Nov 2011 19:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.491 X-Spam-Level: X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g1mnARr7JvV for ; Tue, 8 Nov 2011 19:33:29 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0EAA21F888A for ; Tue, 8 Nov 2011 19:33:28 -0800 (PST) Received: by vws5 with SMTP id 5so1292631vws.31 for ; Tue, 08 Nov 2011 19:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=ZX8EpTmJ7+SVQqbCRVWFrnYRnzLokMhgfUMyB1nNQd4=; b=uULZjm6PgiPg9ifDL6C3A7nuTiPXH+OGjL2f7PpftUaFnzlVPrx2rzkywBeBn2+5bR kTrIrCjzFFhRvggJzp6eq1J+E1DBMCszXL0zfVOJFIUlQ6XTNn7gXrpPjgS3BXYneFer Ms58hF0h2H5K/o/02eAq9/2B5DaCAG/y48CO0= Received: by 10.52.26.47 with SMTP id i15mr1289004vdg.0.1320809608279; Tue, 08 Nov 2011 19:33:28 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id b4sm5500389vda.7.2011.11.08.19.33.24 (version=SSLv3 cipher=OTHER); Tue, 08 Nov 2011 19:33:27 -0800 (PST) Message-ID: <4EB9F483.2040608@gmail.com> Date: Wed, 09 Nov 2011 16:33:23 +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: <4EAF0384.1050002@gmail.com> <1be201cc98b3$249d7a90$6dd86fb0$@com> <4EB6EBEB.2010600@gmail.com> <02f701cc9d89$5ad65ca0$108315e0$@com> <4EB9DE53.70805@gmail.com> <03bc01cc9e8d$0d27ef00$2777cd00$@com> In-Reply-To: <03bc01cc9e8d$0d27ef00$2777cd00$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 'Prashanth Patil' , behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:33:30 -0000 Hi again, On 2011-11-09 16:09, Dan Wing wrote: >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Tuesday, November 08, 2011 5:59 PM >> To: Dan Wing >> Cc: 'Prashanth Patil'; behave@ietf.org >> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure= - >> 00.txt >> >> Dan, >> >>> Our proposal does not force dual-stack hosts to resolve DNS using >>> IPv4 transport (DNS-over-IPv4). >> I must have misunderstood again. It seems to me that this is exactly >> the effect of the following process: >> >> 1. *IPv6-only transition to Dual-Stack* In case a host is IPv6-onl= y >> to start off, it is provided a DNS64 Server. When transitionin= g >> to dual-stack, a IPv4 DNS Server is assigned as a consequence o= f >> obtaining an IPv4 Address. The DHCPv6 Relay Agent can detect >> this and send RELAY-RECONFIG message Section 4.1 to the DHCPv6 >> Server indicating that the host needs to be needs to be provide= d >> with "normal" DNS Server followed by DNS64 server. >> >> That would give it an IPv4-mapped address for DNS service, which it >> would therefore access using native IPv4. >=20 > Ah, because we define: >=20 > 'normal' DNS server : DNS server using an IPv4-mapped IPv6 address > (that is, an IPv6 address starting with ::ffff:/96 IPv4-mapped > prefix). Hosts can communicate with 'normal' DNS server only using > IPv4 packets [RFC6052], section 4.2. >=20 > Yes, agreed, that is how the text is written. This whole idea was > built around "how can we improve draft-wing-behave-dns64-config", > which did the IPv4-mapped address trick -- that trick just doesn't > always work. >=20 > So, until we can update the I-D, imagine that the definition of > "normal DNS server" is "a DNS server that is not performing DNS64 > functions". Said another way, "normal DNS server" is a normal > DNS server that is found on nearly 100% of networks today that > does not synthesize AAAA records. >=20 > With that change, would you have an objection? Sure, we can separate the issues that way. > But, back to your objection -- what's the problem with a dual-stack > host sending its DNS queries over IPv4? The only issue I see is > 1. it is impure As are many aspects of DNS64, so I suppose we have to ignore that. > 2. if IPv4 address sharing is on the path between the client and > DNS server, the DNS queries will consume UDP and TCP ports.=20 True, but for a network of any size, that would be crazy placement of the DNS server, IMHO. > Are there other objections to sending DNS queries over IPv4? It goes against the general strategy of getting as much traffic as possible onto v6 (assuming equal efficiency). I think this matters sociologically. On a network with equal numbers of v4-only, v6-only and dual stack hosts, we would see 67% of DNS traffic still over v4, instead of 67% already over v6. The message to management is very different. I can't pretend that this is a technical objection ;-) Brian >=20 > -d >=20 >=20 >> Regards >> Brian >> >> On 2011-11-08 09:10, Dan Wing wrote: >>>> -----Original Message----- >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>> Sent: Sunday, November 06, 2011 12:20 PM >>>> To: Dan Wing >>>> Cc: 'Prashanth Patil'; behave@ietf.org >>>> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6- >> reconfigure- >>>> 00.txt >>>> >>>> On 2011-11-02 05:27, Dan Wing wrote: >>>>>> -----Original Message----- >>>>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>>>>> Behalf Of Brian E Carpenter >>>>>> Sent: Monday, October 31, 2011 1:22 PM >>>>>> To: Prashanth Patil >>>>>> Cc: behave@ietf.org >>>>>> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6- >>>> reconfigure- >>>>>> 00.txt >>>>>> >>>>>> I don't get it. If a host is dual stacked it can be configured >> with >>>>>> any DNS server, as long as it is not a DNS64. If you can have a >>>>>> DNS64 directly visible, and a v4-only DNS server directly visible,= >>>>>> you are on a dual stack network, so you can also have a dual stack= >>>>>> DNS server directly visible. >>>>> It is anticipated that a network will have a mix of IPv4-only, >>>>> IPv6-only, and dual-stack hosts. The hosts don't know if they >>>>> need a 'normal' DNS server or a DNS64, nor do we have a way >>>>> to tell them the difference. >>>> Indeed not, it is for the DHCPv6 server to ensure that the IPv6-only= >>>> hosts are pointed to the abnormal DNS server (i.e. the DNS64 >> server). >>>> I'm left very uncomfortable by this kludge. Forcing dual-stack hosts= >>>> to resolve DNS via IPv4 seems backwards. >>> Our proposal does not force dual-stack hosts to resolve DNS using >>> IPv4 transport (DNS-over-IPv4). >>> >>>> Also, how will this help on a network that is using RFC 6106? >>>> DHCPv6 isn't mandatory afaik. >>> The RA-versus-DHCPv6 controversy is not unique to this idea, >>> of course. >>> >>> Let's see if the idea has merit; if it does, we can describe >>> how to provide similar functionality using unicast RA. >>> >>> -d >>> >>> >>>> Brian >>>> >>>>> This I-D attempts to provide a solution to that problem of a >>>>> network with a mix of hosts that need to be configured with a >>>>> 'normal' DNS server and DNS64 server. We believe the underlying >>>>> idea (to "poke" a host to tell it something changed on the >>>>> network) appears to have other applicability beyond the DNS/DNS64 >>>>> use-case, as well. >>>>> >>>>> -d >>>>> >>>>> >>>>>> Regards >>>>>> Brian Carpenter >>>>>> >>>>>> On 2011-11-01 05:05, Prashanth Patil wrote: >>>>>>> Hi Brian, >>>>>>> The idea behind the proposal is to provision a means by which >>>> traffic >>>>>> is >>>>>>> sent using IPv4 and not through the IPv6/IPv4 translator. The >>>>>> advantage >>>>>>> being that if NAT44 and NAT64 are deployed on the same network, >> it >>>> is >>>>>>> preferable to use NAT44 over NAT64 because of scale, performance >>>> and >>>>>>> application incompatibility issues (e.g., FTP) [RFC6384]. >>>>>>> A "normal" DNS server does not have DNS64 capability. The IPv4- >>>> mapped >>>>>>> address for this "normal" server ensures that it can be reached >>>> only >>>>>> by >>>>>>> IPv4=C5=A1. So if a host is IPv4-only, it will send a DNS query t= o the >>>>>> "normal" >>>>>>> server just to get the A records. If the host is dual-stack it >> will >>>>>> also >>>>>>> send a DNS query to the "normal" server to get both A and AAAA >>>>>> records. If >>>>>>> the destination address is an IPv4 address, dual-stack host just= >>>>>> gets A >>>>>>> records but not synthesized AAAA records. So this technique will >>>>>> ensure that >>>>>>> IPv4 is preferred over the IPv6/IPv4 translator prefix and also >>>> gives >>>>>> native >>>>>>> IPv6 higher precedence than IPv4. >>>>>>> If the host happens to be IPv6 only, then it cannot reach the >>>>>> "normal" >>>>>>> server because it has IPv4-mapped prefix as explained previously.= >>>> So >>>>>> IPv6 >>>>>>> only host can only reach DNS64 server. So this host will send the= >>>> DNS >>>>>> query >>>>>>> to DNS64 to get AAAA records. Based on the destination address >> the >>>>>> host will >>>>>>> get IPv4-embedded IPv6 address or just the global IPv6 address. >>>>>>> >>>>>>> =C5=A1Note: From RFC 6052 >>>>>>> =C2=B3When presented with the IPv4-mapped prefix, current version= s of >>>>>> Windows and >>>>>>> Mac OS generate IPv4 packets, but will not send IPv6 packets.=C2=B2= >>>>>>> >>>>>>> -Prashanth >>>>>>> >>>>>>> On 22/10/11 6:20 AM, Brian E Carpenter wrote: >>>>>>>> I have a basic question. Why does this draft define a 'normal' >>>>>>>> DNS server as one having an IPv4-mapped IPv6 address? >>>>>>>> >>>>>>>> That seems like a completely *abnormal* DNS server for a dual >>>>>>>> stack host. A dual stack host should normally have a DNS server >>>>>>>> with a regular IPv6 address that will return both A and AAAA >>>>>>>> records if they exist. Normally the server will be dual stacked >>>>>>>> anyway, and will return exactly the same response whether the >>>>>>>> query arrives via v4 or v6. >>>>>>>> >>>>>>>> A DNS server which only has an IPv4 address will also return >>>>>>>> A and AAAA records if they exist, so there is absolutely no >>>>>>>> difference as far as the dual stack host is concerned anyway. >>>>>>>> So what is the point in using the IPv4-mapped address? >>>>>>>> >>>>>>>> Regards >>>>>>>> Brian >>>>>>>> >>>>>>>> On 2011-10-18 11:17, internet-drafts@ietf.org wrote: >>>>>>>>> A New Internet-Draft is available from the on-line Internet- >>>> Drafts >>>>>>>>> directories. >>>>>>>>> >>>>>>>>> Title : DHCPv6 Dynamic Re-Configuration >>>>>>>>> Author(s) : Dan Wing >>>>>>>>> Tirumaleswar Reddy >>>>>>>>> Prashanth Patil >>>>>>>>> Filename : draft-wing-behave-dhcpv6-reconfigure- >> 00.txt >>>>>>>>> Pages : 10 >>>>>>>>> Date : 2011-10-17 >>>>>>>>> >>>>>>>>> Some networks are expected to support IPv4-only, dual- >> stack, >>>>>> and >>>>>>>>> IPV6-only hosts at the same time. This makes prioritizing >>>> the >>>>>> DNS >>>>>>>>> servers for hosts tricky due to a heterogeneous mix of >>>> protocol >>>>>>>>> stacks causing optimal behavior to occur only when the host= >>>>>> stack re- >>>>>>>>> initializes. The networks infrastructure is usually well >>>>>> equipped to >>>>>>>>> be aware of single/dual-stack nature of hosts. This >>>>>> specification >>>>>>>>> extends DHCPv6 so that the DHCPv6 Relay Agent can >> dynamically >>>>>>>>> influence the priority of DNS servers provided to the host,= >>>> so >>>>>> that >>>>>>>>> the host can use the optimal DNS server for resolution. >>>>>>>>> >>>>>>>>> >>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>> http://www.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- >>>>>> reconfigure-00.t >>>>>>>>> xt >>>>>>>>> >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>> >>>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- >>>>>> reconfigure-00.tx >>>>>>>>> t >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >=20 From brian.e.carpenter@gmail.com Tue Nov 8 19:40:41 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0762A11E8073 for ; Tue, 8 Nov 2011 19:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.493 X-Spam-Level: X-Spam-Status: No, score=-103.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meJKSmYd1+ky for ; Tue, 8 Nov 2011 19:40:40 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 55A9521F8A7A for ; Tue, 8 Nov 2011 19:40:40 -0800 (PST) Received: by vws5 with SMTP id 5so1296246vws.31 for ; Tue, 08 Nov 2011 19:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=us+BBMm32dZGuNT7TtRktAnk+PXlNfA7f3rEtdJ0I0U=; b=Sb04Sar6KsXYa6nO3cVXgj7k/SLsgsx9OFAuCn6TPd0yokIyNkd4lPJe5bhAarIfZw bBL/CUgv5DRtnxin1iG5y5W5dDBrgyA7xpT3QVB0gKLfE5J3S2SrNQFg0HBD7DVwqJQh ltBHmLARXjF2bYYUp9u00W5PQMkQrrSkEr4g8= Received: by 10.52.37.36 with SMTP id v4mr1168938vdj.61.1320810039600; Tue, 08 Nov 2011 19:40:39 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id f7sm5508173vdj.13.2011.11.08.19.40.37 (version=SSLv3 cipher=OTHER); Tue, 08 Nov 2011 19:40:38 -0800 (PST) Message-ID: <4EB9F630.4040008@gmail.com> Date: Wed, 09 Nov 2011 16:40:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Sullivan References: <4EB9E1E0.1070501@gmail.com> <20111109033003.GL78156@shinkuro.com> In-Reply-To: <20111109033003.GL78156@shinkuro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 detecting dual stack clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:40:41 -0000 Andrew, I should have started with a problem statement. The administrator has to deal with a network with some dual stack hosts and some IPv6-only hosts, only has the blunt instruments of DHCPv6 or RFC 6106 to tell the hosts about DNS servers, and doesn't know which hosts are which. Yes, it's a kludge on a kludge. It might just be preferable to the one I've been arguing with Dan about (draft-wing-behave-dhcpv6-reconfigure), but it's still a kludge. Brian On 2011-11-09 16:30, Andrew Sullivan wrote: > This is not to pick on Brian. But he provides the occasion. > > On Wed, Nov 09, 2011 at 03:13:52PM +1300, Brian E Carpenter wrote: >> Maybe this has been discussed before, but it seems to me that a DNS64 can >> figure out which clients are dual stack and act accordingly. > > What is the "act accordingly" that is the right thing here? > > > > I am sick unto death of suggestions to make DNS64+NAT64 work more > reliably. It is a nasty, 80% solution hack. I cannot speak for > anyone else involved with it, but to me it was _always_ supposed to be > a nasty hack -- useful as a kind of field bandage for the most > egregious problems caused by the fact that there was no real IPv4-IPv6 > upgrade path. We live in a world with no more IPv4 network addresses > and little IPv6 penetration; and also one where "the Internet", for > many people, means "what I get in my browser." I have taken as my > motto a sort of Homer Simpson one: "Aim low." If we can mostly fix > things most of the time for the most common case, it's useful. It's > still a nasty hack, but it's useful for now. > > > > In my opinion, "act accordingly" is to get out one of those > muzzle-loading-cannon-on-scissors that is so popular in Warner Bros > cartoons, and shoot it at the network administrator who configured > some poor slob's computer with a dual stack and a NAT64. > > Any other case -- like solving the case where I somehow accidentally > stumble onto a NAT64 network with an unmolested IPv4 connection that > nobody knows about -- sounds to me like an optimization that shouldn't > be considered. If the complaint is, "Yes, but then people will use > NAT when they don't have to," I express my doubts. An infinitesimally > small number of people use unmolested, NAT-free IPv4 today. Those > people already know how to cope with IPv6 and how to avoid sludge like > NAT64. Everybody else just has a crappy choice of NATs to make. > > If the argument is instead that we can make protocols with embedded > IPv4 literals in them work marginally better this way, then I suggest > the additional complications are not worth making for protocols that > are wrong in their conception to begin with. > > Please, let us not fix something that is broken exactly as much as it > ought to be. The pig is wearing enough lipstick. We should put away > the cosmetics now. > > A From dwing@cisco.com Tue Nov 8 19:46:04 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F2E11E80C3 for ; Tue, 8 Nov 2011 19:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.648 X-Spam-Level: X-Spam-Status: No, score=-105.648 tagged_above=-999 required=5 tests=[AWL=0.951, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBLxfvuTpkLW for ; Tue, 8 Nov 2011 19:46:03 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD0021F8A97 for ; Tue, 8 Nov 2011 19:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=12660; q=dns/txt; s=iport; t=1320810361; x=1322019961; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=sa1TmYWhfW4wveT7vbbAEpTc2JWj7i2+6iMuxlPtKo0=; b=SJCebTICQB8PC+bkmqsbkTXUurFGeBwyQkiTXbRnLJcByu6Yirwc7JLP iIhFu0CKlP7WIfIgxTG4qCFwfCuiXcU1/Ftf8t+SUQ/fI1n5/fY1fNhH4 XtEEdSWXfQ9i1r20+3Lmt6tEf1rl5Aa4ZhP2Y3JoUsnrHBYxYuAs5HWyR Y=; X-IronPort-AV: E=Sophos;i="4.69,481,1315180800"; d="scan'208";a="13118843" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 09 Nov 2011 03:46:01 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA93k0rf026242; Wed, 9 Nov 2011 03:46:00 GMT From: "Dan Wing" To: "'Brian E Carpenter'" References: <4EAF0384.1050002@gmail.com> <1be201cc98b3$249d7a90$6dd86fb0$@com> <4EB6EBEB.2010600@gmail.com> <02f701cc9d89$5ad65ca0$108315e0$@com> <4EB9DE53.70805@gmail.com> <03bc01cc9e8d$0d27ef00$2777cd00$@com> <4EB9F483.2040608@gmail.com> In-Reply-To: <4EB9F483.2040608@gmail.com> Date: Tue, 8 Nov 2011 19:46:00 -0800 Message-ID: <03c501cc9e92$18f7d250$4ae776f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyekFqihARswNVxS1+xM7ZHn35v4gAAGKvg Content-Language: en-us Cc: 'Prashanth Patil' , behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:46:04 -0000 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Tuesday, November 08, 2011 7:33 PM > To: Dan Wing > Cc: 'Prashanth Patil'; behave@ietf.org > Subject: Re: [BEHAVE] I-D Action: = draft-wing-behave-dhcpv6-reconfigure- > 00.txt >=20 > Hi again, >=20 > On 2011-11-09 16:09, Dan Wing wrote: > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: Tuesday, November 08, 2011 5:59 PM > >> To: Dan Wing > >> Cc: 'Prashanth Patil'; behave@ietf.org > >> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6- > reconfigure- > >> 00.txt > >> > >> Dan, > >> > >>> Our proposal does not force dual-stack hosts to resolve DNS using > >>> IPv4 transport (DNS-over-IPv4). > >> I must have misunderstood again. It seems to me that this is = exactly > >> the effect of the following process: > >> > >> 1. *IPv6-only transition to Dual-Stack* In case a host is IPv6- > only > >> to start off, it is provided a DNS64 Server. When > transitioning > >> to dual-stack, a IPv4 DNS Server is assigned as a = consequence > of > >> obtaining an IPv4 Address. The DHCPv6 Relay Agent can = detect > >> this and send RELAY-RECONFIG message Section 4.1 to the > DHCPv6 > >> Server indicating that the host needs to be needs to be > provided > >> with "normal" DNS Server followed by DNS64 server. > >> > >> That would give it an IPv4-mapped address for DNS service, which it > >> would therefore access using native IPv4. > > > > Ah, because we define: > > > > 'normal' DNS server : DNS server using an IPv4-mapped IPv6 = address > > (that is, an IPv6 address starting with ::ffff:/96 IPv4-mapped > > prefix). Hosts can communicate with 'normal' DNS server only > using > > IPv4 packets [RFC6052], section 4.2. > > > > Yes, agreed, that is how the text is written. This whole idea was > > built around "how can we improve draft-wing-behave-dns64-config", > > which did the IPv4-mapped address trick -- that trick just doesn't > > always work. > > > > So, until we can update the I-D, imagine that the definition of > > "normal DNS server" is "a DNS server that is not performing DNS64 > > functions". Said another way, "normal DNS server" is a normal > > DNS server that is found on nearly 100% of networks today that > > does not synthesize AAAA records. > > > > With that change, would you have an objection? >=20 > Sure, we can separate the issues that way. >=20 > > But, back to your objection -- what's the problem with a dual-stack > > host sending its DNS queries over IPv4? The only issue I see is > > 1. it is impure >=20 > As are many aspects of DNS64, so I suppose we have to ignore that. >=20 > > 2. if IPv4 address sharing is on the path between the client and > > DNS server, the DNS queries will consume UDP and TCP ports. >=20 > True, but for a network of any size, that would be crazy placement > of the DNS server, IMHO. Agreed. But some parents use "parental control" DNS servers, some geeks use Google's or HE's nameservers, and some corporate users use their company's "hidden" (unpublished) nameservers (split-zone=20 DNS). Those will cross a NAT. > > Are there other objections to sending DNS queries over IPv4? >=20 > It goes against the general strategy of getting as much traffic > as possible onto v6 (assuming equal efficiency). >=20 > I think this matters sociologically. On a network with equal numbers > of v4-only, v6-only and dual stack hosts, we would see 67% of DNS > traffic still over v4, instead of 67% already over v6. The message > to management is very different. >=20 > I can't pretend that this is a technical objection ;-) Ok. I'm trying to see if there is a technical objection somewhere in there; I think sending DNS queries over a NAT is one. But, that can be handled reasonably well by vendors doing fancier things for port 53 (e.g., shorter time outs). -d > Brian >=20 > > > > -d > > > > > >> Regards > >> Brian > >> > >> On 2011-11-08 09:10, Dan Wing wrote: > >>>> -----Original Message----- > >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >>>> Sent: Sunday, November 06, 2011 12:20 PM > >>>> To: Dan Wing > >>>> Cc: 'Prashanth Patil'; behave@ietf.org > >>>> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6- > >> reconfigure- > >>>> 00.txt > >>>> > >>>> On 2011-11-02 05:27, Dan Wing wrote: > >>>>>> -----Original Message----- > >>>>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] > On > >>>>>> Behalf Of Brian E Carpenter > >>>>>> Sent: Monday, October 31, 2011 1:22 PM > >>>>>> To: Prashanth Patil > >>>>>> Cc: behave@ietf.org > >>>>>> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6- > >>>> reconfigure- > >>>>>> 00.txt > >>>>>> > >>>>>> I don't get it. If a host is dual stacked it can be configured > >> with > >>>>>> any DNS server, as long as it is not a DNS64. If you can have a > >>>>>> DNS64 directly visible, and a v4-only DNS server directly > visible, > >>>>>> you are on a dual stack network, so you can also have a dual > stack > >>>>>> DNS server directly visible. > >>>>> It is anticipated that a network will have a mix of IPv4-only, > >>>>> IPv6-only, and dual-stack hosts. The hosts don't know if they > >>>>> need a 'normal' DNS server or a DNS64, nor do we have a way > >>>>> to tell them the difference. > >>>> Indeed not, it is for the DHCPv6 server to ensure that the IPv6- > only > >>>> hosts are pointed to the abnormal DNS server (i.e. the DNS64 > >> server). > >>>> I'm left very uncomfortable by this kludge. Forcing dual-stack > hosts > >>>> to resolve DNS via IPv4 seems backwards. > >>> Our proposal does not force dual-stack hosts to resolve DNS using > >>> IPv4 transport (DNS-over-IPv4). > >>> > >>>> Also, how will this help on a network that is using RFC 6106? > >>>> DHCPv6 isn't mandatory afaik. > >>> The RA-versus-DHCPv6 controversy is not unique to this idea, > >>> of course. > >>> > >>> Let's see if the idea has merit; if it does, we can describe > >>> how to provide similar functionality using unicast RA. > >>> > >>> -d > >>> > >>> > >>>> Brian > >>>> > >>>>> This I-D attempts to provide a solution to that problem of a > >>>>> network with a mix of hosts that need to be configured with a > >>>>> 'normal' DNS server and DNS64 server. We believe the underlying > >>>>> idea (to "poke" a host to tell it something changed on the > >>>>> network) appears to have other applicability beyond the = DNS/DNS64 > >>>>> use-case, as well. > >>>>> > >>>>> -d > >>>>> > >>>>> > >>>>>> Regards > >>>>>> Brian Carpenter > >>>>>> > >>>>>> On 2011-11-01 05:05, Prashanth Patil wrote: > >>>>>>> Hi Brian, > >>>>>>> The idea behind the proposal is to provision a means by which > >>>> traffic > >>>>>> is > >>>>>>> sent using IPv4 and not through the IPv6/IPv4 translator. The > >>>>>> advantage > >>>>>>> being that if NAT44 and NAT64 are deployed on the same = network, > >> it > >>>> is > >>>>>>> preferable to use NAT44 over NAT64 because of scale, > performance > >>>> and > >>>>>>> application incompatibility issues (e.g., FTP) [RFC6384]. > >>>>>>> A "normal" DNS server does not have DNS64 capability. The = IPv4- > >>>> mapped > >>>>>>> address for this "normal" server ensures that it can be = reached > >>>> only > >>>>>> by > >>>>>>> IPv4=C5=A1. So if a host is IPv4-only, it will send a DNS = query to > the > >>>>>> "normal" > >>>>>>> server just to get the A records. If the host is dual-stack it > >> will > >>>>>> also > >>>>>>> send a DNS query to the "normal" server to get both A and AAAA > >>>>>> records. If > >>>>>>> the destination address is an IPv4 address, dual-stack host > just > >>>>>> gets A > >>>>>>> records but not synthesized AAAA records. So this technique > will > >>>>>> ensure that > >>>>>>> IPv4 is preferred over the IPv6/IPv4 translator prefix and = also > >>>> gives > >>>>>> native > >>>>>>> IPv6 higher precedence than IPv4. > >>>>>>> If the host happens to be IPv6 only, then it cannot reach the > >>>>>> "normal" > >>>>>>> server because it has IPv4-mapped prefix as explained > previously. > >>>> So > >>>>>> IPv6 > >>>>>>> only host can only reach DNS64 server. So this host will send > the > >>>> DNS > >>>>>> query > >>>>>>> to DNS64 to get AAAA records. Based on the destination address > >> the > >>>>>> host will > >>>>>>> get IPv4-embedded IPv6 address or just the global IPv6 = address. > >>>>>>> > >>>>>>> =C5=A1Note: From RFC 6052 > >>>>>>> =C2=B3When presented with the IPv4-mapped prefix, current = versions > of > >>>>>> Windows and > >>>>>>> Mac OS generate IPv4 packets, but will not send IPv6 = packets.=C2=B2 > >>>>>>> > >>>>>>> -Prashanth > >>>>>>> > >>>>>>> On 22/10/11 6:20 AM, Brian E Carpenter wrote: > >>>>>>>> I have a basic question. Why does this draft define a = 'normal' > >>>>>>>> DNS server as one having an IPv4-mapped IPv6 address? > >>>>>>>> > >>>>>>>> That seems like a completely *abnormal* DNS server for a dual > >>>>>>>> stack host. A dual stack host should normally have a DNS > server > >>>>>>>> with a regular IPv6 address that will return both A and AAAA > >>>>>>>> records if they exist. Normally the server will be dual > stacked > >>>>>>>> anyway, and will return exactly the same response whether the > >>>>>>>> query arrives via v4 or v6. > >>>>>>>> > >>>>>>>> A DNS server which only has an IPv4 address will also return > >>>>>>>> A and AAAA records if they exist, so there is absolutely no > >>>>>>>> difference as far as the dual stack host is concerned anyway. > >>>>>>>> So what is the point in using the IPv4-mapped address? > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> On 2011-10-18 11:17, internet-drafts@ietf.org wrote: > >>>>>>>>> A New Internet-Draft is available from the on-line Internet- > >>>> Drafts > >>>>>>>>> directories. > >>>>>>>>> > >>>>>>>>> Title : DHCPv6 Dynamic Re-Configuration > >>>>>>>>> Author(s) : Dan Wing > >>>>>>>>> Tirumaleswar Reddy > >>>>>>>>> Prashanth Patil > >>>>>>>>> Filename : draft-wing-behave-dhcpv6-reconfigure- > >> 00.txt > >>>>>>>>> Pages : 10 > >>>>>>>>> Date : 2011-10-17 > >>>>>>>>> > >>>>>>>>> Some networks are expected to support IPv4-only, dual- > >> stack, > >>>>>> and > >>>>>>>>> IPV6-only hosts at the same time. This makes > prioritizing > >>>> the > >>>>>> DNS > >>>>>>>>> servers for hosts tricky due to a heterogeneous mix of > >>>> protocol > >>>>>>>>> stacks causing optimal behavior to occur only when the > host > >>>>>> stack re- > >>>>>>>>> initializes. The networks infrastructure is usually = well > >>>>>> equipped to > >>>>>>>>> be aware of single/dual-stack nature of hosts. This > >>>>>> specification > >>>>>>>>> extends DHCPv6 so that the DHCPv6 Relay Agent can > >> dynamically > >>>>>>>>> influence the priority of DNS servers provided to the > host, > >>>> so > >>>>>> that > >>>>>>>>> the host can use the optimal DNS server for resolution. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> A URL for this Internet-Draft is: > >>>>>>>>> = http://www.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- > >>>>>> reconfigure-00.t > >>>>>>>>> xt > >>>>>>>>> > >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>>>>> > >>>>>>>>> This Internet-Draft can be retrieved at: > >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-wing-behave-dhcpv6- > >>>>>> reconfigure-00.tx > >>>>>>>>> t > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 ajs@anvilwalrusden.com Tue Nov 8 19:51:54 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2911F0C3B for ; Tue, 8 Nov 2011 19:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFoPYyDJo5W3 for ; Tue, 8 Nov 2011 19:51:53 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C3FE61F0C47 for ; Tue, 8 Nov 2011 19:51:53 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 106861ECB41D for ; Wed, 9 Nov 2011 03:51:41 +0000 (UTC) Date: Tue, 8 Nov 2011 22:51:51 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20111109035150.GN78156@shinkuro.com> References: <4EB9E1E0.1070501@gmail.com> <20111109033003.GL78156@shinkuro.com> <4EB9F630.4040008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB9F630.4040008@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] DNS64 detecting dual stack clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:51:54 -0000 On Wed, Nov 09, 2011 at 04:40:32PM +1300, Brian E Carpenter wrote: > has to deal with a network with some dual stack hosts and some > IPv6-only hosts, only has the blunt instruments of DHCPv6 or RFC 6106 > to tell the hosts about DNS servers, and doesn't know which > hosts are which. How did the network administrator build such a preposterous network, though? This sounds like an excellent example of the fellow who goes to the doctor complaining about the pain caused when he hits himself in the face. The dual-stack people should simply be provisioned separately. "Don't do that" seems to me to be to be a perfectly legitimate response to this kind of problem, and I don't understand why the request to fix it keeps coming back. I mean, I get why: people are lazy and cheap. But some things can't reasonably be accommodated without causing pain to everyone else. Significantly complicating DNS64 -- interactions with the arp cache? really? -- just so someone can save a few bucks on his provisioning infrastructure sounds to me like a bad deal, unless I'm the guy saving the bucks. But I'll shut up now until I've done a proper job reading the argument between you and Dan, since I confess I've mostly been looking the other way. A -- Andrew Sullivan ajs@anvilwalrusden.com From stephan.lagerholm@secure64.com Tue Nov 8 20:01:32 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5265F1F0C44 for ; Tue, 8 Nov 2011 20:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQL4sU6APRaT for ; Tue, 8 Nov 2011 20:01:31 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1801F0C51 for ; Tue, 8 Nov 2011 20:01:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 1A44AB84A5; Tue, 8 Nov 2011 21:01:31 -0700 (MST) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DA2-orb5K694; Tue, 8 Nov 2011 21:01:30 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id ECA48B8497; Tue, 8 Nov 2011 21:01:29 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1320811290; bh=qGtcKgPZjM5tUCunwuT5oLm+7w1VF853mJgn1U7sRwU=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To; b=YmY/proQoZlYV20TDiLLv NQAB9lP02r4ZLZTt3zBXql7qhlGlPh1S/XldUUeWmZn7kYFvf7Ql6t5Ju2LpVSiysMw 5zzzx5ysW7QSnaU1rNzmS5jYz0cJqTXHHkxUqgi3d65iGYtAxmbd99F+qJYlZHChOAT TNH2n9jC+fEUF6TU= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Nov 2011 21:00:20 -0700 Message-ID: In-Reply-To: <4EB9E1E0.1070501@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] DNS64 detecting dual stack clients Thread-Index: AcyehUAIefSgUBdqRVyRK1cxtylDrQADnA/A References: <4EB9E1E0.1070501@gmail.com> From: "Stephan Lagerholm" To: "Brian E Carpenter" , Subject: Re: [BEHAVE] DNS64 detecting dual stack clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 04:01:32 -0000 Tue 11/8/2011 8:14 PM Brian Carpenter wrote: > Maybe this has been discussed before, but it seems to me that a DNS64 > can figure out which clients are dual stack and act accordingly. >=20 > * The DNS64 runs on a box which is dual stacked. In fact, it will > contain a straight dual-stack DNS server as well as a DNS64. They schmooze. >=20 > * The box has an ARP cache and an ND cache. >=20 > * Whenever a new host appears in the ARP cache, the box checks the MAC > address against the ND cache, and vice versa. That would only work if the client and the DNS server both are on the same L2 segment.=20 /Stephan From jounikor@gmail.com Tue Nov 8 09:09:21 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A879321F88A0 for ; Tue, 8 Nov 2011 09:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cyZMa2y77nv for ; Tue, 8 Nov 2011 09:09:20 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 586F521F84FB for ; Tue, 8 Nov 2011 09:09:17 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so758605bkb.31 for ; Tue, 08 Nov 2011 09:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=fbPPyz1LhDogJNGKWqDCtTNpoexfVhXcDBmpGMrzGKY=; b=YoSxhtJHh5Ipc835mU9b3NLiSWK1VXS1hay0SFTxzV+ITFKvU1NXJA2j6LhV609A5f IeM1iqtsEQbcTp95I5CyEdsIy+bfBsVaIBjNzhIDkcbMNHSFyzTR3CYJH0EFdxV5yYxk kWh8duegNZck6/i1OpGA99ogwibiJN56sm58A= Received: by 10.204.157.27 with SMTP id z27mr23613937bkw.8.1320772156098; Tue, 08 Nov 2011 09:09:16 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPS id z15sm2184594bkv.4.2011.11.08.09.09.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Nov 2011 09:09:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4EB93876.7090901@viagenie.ca> Date: Tue, 8 Nov 2011 19:09:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB93876.7090901@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 09 Nov 2011 11:15:39 -0800 Cc: behave@ietf.org Subject: Re: [BEHAVE] tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 17:09:21 -0000 Simon, On Nov 8, 2011, at 4:11 PM, Simon Perreault wrote: > jouni korhonen wrote, on 11/08/2011 04:51 AM: >> Also, STUN >> protocol would be needed to changed on both host and network side to = support >> the discovery of NAT64 >=20 > Would it? Please explain why. Because of the text few WG participants wanted us to included into the = analysis when using STUN for NAT64 discovery. That resulted to the text = below, which very much implies protocol work to me: After learning the IPv6 address of a STUN server the STUN client sends a request to the STUN server containing new 'SENDING-TO' attribute that tells to the server the IPv6 address the client sent the request to. In a reply the server includes another new attribute called 'RECEIVED-AS', which contains server's IP address the request arrived on. After receiving the reply the client compares 'SENDING-TO' and 'RECEIVED-AS' attributes to find out an NSP candidate. - JOuni >=20 > If you send a STUN request using IPv6 transport and get a reply = containing an > IPv4 mapped address, you can be pretty sure that you're behind some = kind of NAT64... >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From despres.remi@laposte.net Tue Nov 8 10:01:21 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEE421F844E; Tue, 8 Nov 2011 10:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI4oYbacxJmB; Tue, 8 Nov 2011 10:01:21 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id CFD7511E80B3; Tue, 8 Nov 2011 10:01:20 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id 8B9C57000182; Tue, 8 Nov 2011 19:01:19 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id BAE957000188; Tue, 8 Nov 2011 19:01:14 +0100 (CET) X-SFR-UUID: 20111108180114765.BAE957000188@msfrf2214.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 8 Nov 2011 19:01:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Reinaldo Penno , Alain Durand X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 09 Nov 2011 11:15:39 -0800 Cc: "softwires@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] Stateless Deterministic NAPT/DS-Lite X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 18:01:21 -0000 Reinaldo, Alain, Lionel, Nicely written document. Here are a few points: 1. Other stateless solutions and DS-lite The introduction suggests that other stateless solutions resulted from = "efforts to evolve the DS-lite model", this isn't really how they were = designed:=20 - The DS-lite model is AFAIK based on . RFC-1918 addresses being the only IPv4 addresses that traverse the = ISP network . NATs within the ISP infrastructure . Hub-and-spoke topologies (mesh topologies excluded) =20 - Works on 4rd and A+P excluded since the origin these three features. = They are based on: . Public IPv4 addresses across ISP networks=20 . IP-payload transparency (no NAT) . Support of mesh topologies (with hub and spoke possible as a limit = case) 2. IPv4 address-pool modifications The draft asserts that SDNAT is necessarily better than stateless = solutions to "add and remove addresses from the NAT pool", but doesn't = explain. This isn't clear to me, in particular because sec. 2.1 says "the SD-CPE = can learn the external address it is mapped to using the PCP protocol".=20= Changing the IPv4 address pool seems therefore to have consequences = similar to those of solutions that provide addresses and port sets in = DHCP. On the other hand, with a lifetime applicable to mapping rules, it is = possible with other stateless solutions to plan a replacement of = obsolete mapping rules by new ones. The time during which IPv4 is = unavailable needs not to be long.=20 3. Number of ports in IPv6 addresses=20 The draft asserts that, with other stateless solutions, "the number of = IPv4 port allocated per subscriber is encoded in the IPv6 address".=20 There were such proposals, but also proposals that didn't have it. This isn't AFAIK a requirement of the MAP design team. 4. IPv4-only ISP access networks (6rd + 4rd also works!) A claimed advantage is that SD-CPEs "can remain IPv4-only devices" (IMHO = a strange idea since they have to be upgraded to support SDNAT), and = that "the ISP access network can also remain IPv4-only". On the latter point, note that 6rd can be combined with 4rd (or some = other mesh-compatible stateless solution) for the same result: this = brings, across IPv4-only access networks, both IPv6 service AND IPv4 = residual service.=20 5. Differentiated sharing ratios?=20 To support differentiated CPE sharing ratios several sets of = mapping-function parameters are presumably needed.=20 Their impact on routing plans, and on CGN operation, aren't evaluated. 6. Operational experience A claimed advantage of SD-NAT over double translation solutions is that = there is more operational experience with encapsulation, a consideration = that has limited but real value. But the need of SDNAT to support PCP for incoming connectivity leads to = a world where past experience is very limited.=20 The fact that others stateless solutions don't need PCP should therefore = be noted in the comparison section sec. 7.2. In view of the above, the need for one more standard is unclear to me.=20= (A Mesh-capable solution also works for hub-and-spoke topologies, and = can easily be added to CGNs).=20 Regards, RD =20 Le 2 nov. 2011 =E0 00:12, Reinaldo Penno a =E9crit : > Hello, >=20 > we submitted a new draft detailing our implementation of > Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT) >=20 > http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 >=20 > This is a based on our experience with port bucket/chunk allocation = and > deterministic NAPT44. In the draft we provide a comparison with other > stateless/stateful methods floating around. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From brian.e.carpenter@gmail.com Wed Nov 9 11:54:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059A511E8080 for ; Wed, 9 Nov 2011 11:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.495 X-Spam-Level: X-Spam-Status: No, score=-103.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDwUR+ArR9YA for ; Wed, 9 Nov 2011 11:54:11 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE79221F848D for ; Wed, 9 Nov 2011 11:54:10 -0800 (PST) Received: by wyf28 with SMTP id 28so98251wyf.31 for ; Wed, 09 Nov 2011 11:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=g+IUb/OFDU4aTngsFMd/txNAnBzexZXPN+1+CINf4BU=; b=j3RRDg+n4EgGGW4kNZAKa7cAMzVRVH0oYml3WQ3knJWmjNBS6nJJlqz5bP2SL0x27+ NQbbV2LeEcfMsIhF6bckVBPBUBt5gbN0CK8YnloVHBldiHfaC5ZOr9ed3Rlmbobgagqq /M/OSVksELjjKdiwXFFaV1oWpLG6GtIkdxMig= Received: by 10.227.206.146 with SMTP id fu18mr2868795wbb.7.1320868449879; Wed, 09 Nov 2011 11:54:09 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id x40sm6797791wbn.19.2011.11.09.11.54.06 (version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 11:54:08 -0800 (PST) Message-ID: <4EBADA4B.7010603@gmail.com> Date: Thu, 10 Nov 2011 08:53:47 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephan Lagerholm , Andrew Sullivan References: <4EB9E1E0.1070501@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 detecting dual stack clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 19:54:12 -0000 On 2011-11-09 17:00, Stephan Lagerholm wrote: > Tue 11/8/2011 8:14 PM Brian Carpenter wrote: >> Maybe this has been discussed before, but it seems to me that a DNS64 >> can figure out which clients are dual stack and act accordingly. >> >> * The DNS64 runs on a box which is dual stacked. In fact, it will >> contain a straight dual-stack DNS server as well as a DNS64. They > schmooze. >> * The box has an ARP cache and an ND cache. >> >> * Whenever a new host appears in the ARP cache, the box checks the MAC >> address against the ND cache, and vice versa. > > That would only work if the client and the DNS server both are on the > same L2 segment. The same *broadcast* L2 segment, in fact. Agreed - but that seems to be the unmanaged case where the problem might arise. On 2011-11-09 16:51, Andrew Sullivan wrote: > How did the network administrator build such a preposterous network, > though? This sounds like an excellent example of the fellow who goes > to the doctor complaining about the pain caused when he hits himself > in the face. > > The dual-stack people should simply be provisioned separately. "Don't > do that" seems to me to be to be a perfectly legitimate response to > this kind of problem... As far as I can see, this would not be adequate on an open-access LAN where hosts are plugged in without warning or planning. In that case, a random mixture of dual stack and v6-only hosts (not to mention v4-only hosts) can happen, and the network manager doesn't know how to provision them. Or it's a homenet and there is no manager. Brian From ajs@anvilwalrusden.com Wed Nov 9 12:15:52 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4511211E8094 for ; Wed, 9 Nov 2011 12:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8GDrZtB4nyP for ; Wed, 9 Nov 2011 12:15:51 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id A70EE11E8090 for ; Wed, 9 Nov 2011 12:15:51 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8F28E1ECB422 for ; Wed, 9 Nov 2011 20:15:38 +0000 (UTC) Date: Wed, 9 Nov 2011 15:15:49 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20111109201548.GN82668@shinkuro.com> References: <4EB9E1E0.1070501@gmail.com> <4EBADA4B.7010603@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EBADA4B.7010603@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] DNS64 detecting dual stack clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:15:52 -0000 On Thu, Nov 10, 2011 at 08:53:47AM +1300, Brian E Carpenter wrote: > As far as I can see, this would not be adequate on an open-access LAN > where hosts are plugged in without warning or planning. In that case, > a random mixture of dual stack and v6-only hosts (not to mention > v4-only hosts) can happen, and the network manager doesn't know > how to provision them. Or it's a homenet and there is no manager. Ok. So they get some extra NAT. Why is that worth making things much more complicated, and not just a cost of deploying a NAT? It's this latter issue that I don't get. Yes, NAT64 means that some things -- even some things that work fine in an IPv4-only world -- stop working or working reliably. But the kinds of things I keep hearing as band-aids all sound to me at least as bad as the disease. For instance, NAT64 + DNS64 is already far too complicated for my liking. The proposals I've seen are all additional complications, and I suspect they won't get deployed because they are just too complicated. My initial reaction (as an old operator) to, "We'll just hook the arp cache to your DNS server, and then you can make differential decisions based on that," is to weep. We know that the original vision of DNS64 + NAT64 already doesn't "just work": it doesn't work for validators on the end point, and it has never just worked for me on my laptop because Apple doesn't have a nice way of getting the right DNS servers to me. Each additional feature and workaround will have yet another bunch of corner cases that makes something less reliable than it would have been. At what point does this make deploying the so-called workaround itself (NAT64 + DNS64) so much trouble that it isn't worth it? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From brian.e.carpenter@gmail.com Wed Nov 9 12:46:24 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1247811E8093 for ; Wed, 9 Nov 2011 12:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.497 X-Spam-Level: X-Spam-Status: No, score=-103.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGrYeXBAVEJP for ; Wed, 9 Nov 2011 12:46:23 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F77211E8080 for ; Wed, 9 Nov 2011 12:46:23 -0800 (PST) Received: by eyg24 with SMTP id 24so2135979eyg.31 for ; Wed, 09 Nov 2011 12:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=aGc6PersB9gbt6q3fc1taj4/LiHA0nXFO2lJsuQbgeg=; b=q7WJ1NN2Nf05fBin2Bf/monHZ615Wghwni2s63usC1A3xWrec8OWs09Zc+0OQ8Fn37 uyncCPbLw2wTebm+sfmVy9jFC6IfbXQpTSIUfPXDHPhfHI2Oiml9kAPusYlwhb7J9cMC e8zWF1FUha79S4lHwozPvgYQsSwc53ZSCUzWo= Received: by 10.180.74.141 with SMTP id t13mr4561751wiv.68.1320871580996; Wed, 09 Nov 2011 12:46:20 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id k5sm3624379wiz.9.2011.11.09.12.46.18 (version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 12:46:20 -0800 (PST) Message-ID: <4EBAE682.9020406@gmail.com> Date: Thu, 10 Nov 2011 09:45:54 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Sullivan References: <4EB9E1E0.1070501@gmail.com> <20111109033003.GL78156@shinkuro.com> <4EB9F630.4040008@gmail.com> <20111109035150.GN78156@shinkuro.com> In-Reply-To: <20111109035150.GN78156@shinkuro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 detecting dual stack clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:46:24 -0000 Andrew, You are basically right, and it's a matter of taste and commercial judgment where to stop with the kludges. The kludge that I proposed is confined to the DNS64 box; the alternative proposal pollutes DHCPv6 as well, which I like even less. The correct answer is clearly for all content providers to offer dual stack service; then the need for NAT64 goes away. (Hence draft-carpenter-v6ops-icp-guidance.) Regards Brian Carpenter On 2011-11-10 09:15, Andrew Sullivan wrote: > On Thu, Nov 10, 2011 at 08:53:47AM +1300, Brian E Carpenter wrote: >> As far as I can see, this would not be adequate on an open-access LAN >> where hosts are plugged in without warning or planning. In that case, >> a random mixture of dual stack and v6-only hosts (not to mention >> v4-only hosts) can happen, and the network manager doesn't know >> how to provision them. Or it's a homenet and there is no manager. > > Ok. So they get some extra NAT. Why is that worth making things much > more complicated, and not just a cost of deploying a NAT? > > It's this latter issue that I don't get. Yes, NAT64 means that some > things -- even some things that work fine in an IPv4-only world -- > stop working or working reliably. But the kinds of things I keep > hearing as band-aids all sound to me at least as bad as the disease. > For instance, NAT64 + DNS64 is already far too complicated for my > liking. The proposals I've seen are all additional complications, and > I suspect they won't get deployed because they are just too > complicated. My initial reaction (as an old operator) to, "We'll just > hook the arp cache to your DNS server, and then you can make > differential decisions based on that," is to weep. > > We know that the original vision of DNS64 + NAT64 already doesn't > "just work": it doesn't work for validators on the end point, and it > has never just worked for me on my laptop because Apple doesn't have a > nice way of getting the right DNS servers to me. Each additional > feature and workaround will have yet another bunch of corner cases > that makes something less reliable than it would have been. At what > point does this make deploying the so-called workaround itself (NAT64 > + DNS64) so much trouble that it isn't worth it? From marka@isc.org Wed Nov 9 14:46:30 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7912311E8087 for ; Wed, 9 Nov 2011 14:46:30 -0800 (PST) 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=[AWL=-0.639, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5RwOV0jjhrl for ; Wed, 9 Nov 2011 14:46:29 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 8E18521F842C for ; Wed, 9 Nov 2011 14:46:29 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id A1EA55F9891; Wed, 9 Nov 2011 22:46:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 7ED56216C6E; Wed, 9 Nov 2011 22:46:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id AC24116F9B60; Thu, 10 Nov 2011 09:45:56 +1100 (EST) To: Brian E Carpenter From: Mark Andrews References: <4EB9E1E0.1070501@gmail.com> <4EBADA4B.7010603@gmail.com> In-reply-to: Your message of "Thu, 10 Nov 2011 08:53:47 +1300." <4EBADA4B.7010603@gmail.com> Date: Thu, 10 Nov 2011 09:45:56 +1100 Message-Id: <20111109224556.AC24116F9B60@drugs.dv.isc.org> Cc: behave@ietf.org, Stephan Lagerholm , Andrew Sullivan Subject: Re: [BEHAVE] DNS64 detecting dual stack clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:46:30 -0000 In message <4EBADA4B.7010603@gmail.com>, Brian E Carpenter writes: > On 2011-11-09 17:00, Stephan Lagerholm wrote: > > Tue 11/8/2011 8:14 PM Brian Carpenter wrote: > >> Maybe this has been discussed before, but it seems to me that a DNS64 > >> can figure out which clients are dual stack and act accordingly. > >> > >> * The DNS64 runs on a box which is dual stacked. In fact, it will > >> contain a straight dual-stack DNS server as well as a DNS64. They > > schmooze. > >> * The box has an ARP cache and an ND cache. > >> > >> * Whenever a new host appears in the ARP cache, the box checks the MAC > >> address against the ND cache, and vice versa. > > > > That would only work if the client and the DNS server both are on the > > same L2 segment. > > The same *broadcast* L2 segment, in fact. Agreed - but that seems to be the > unmanaged case where the problem might arise. > > On 2011-11-09 16:51, Andrew Sullivan wrote: > > > How did the network administrator build such a preposterous network, > > though? This sounds like an excellent example of the fellow who goes > > to the doctor complaining about the pain caused when he hits himself > > in the face. > > > > The dual-stack people should simply be provisioned separately. "Don't > > do that" seems to me to be to be a perfectly legitimate response to > > this kind of problem... > > As far as I can see, this would not be adequate on an open-access LAN > where hosts are plugged in without warning or planning. In that case, > a random mixture of dual stack and v6-only hosts (not to mention > v4-only hosts) can happen, and the network manager doesn't know > how to provision them. Or it's a homenet and there is no manager. > > Brian Why is the IETF persisting with developing DNS64/NAT64 at all? It's a 80% solution when there are alternative solutions that give the level of connectivity we have today in IPv4, that work with DNSSEC, that don't corrupt DNS responses, that work with IPv4 literals, that work with IPv6 only hosts, that work with a network of IPv6-only and dual stacked machines. The only advantage DNS64/NAT64 has is that it doesn't need node/cpe support which meant that it is easier short term solution when you are forced into deploying IPv6 only. DNS64/NAT64 should be seen as a stop gap solution on the way to deploying a more comprehensive solution or as a end stage solution when 99.999% of the world is IPv6 reachable. It just sucks as a general solution for providing IPv4 connectivity. Move the DNS64 re-writing into the nodes and the whole issues of which type of DNS server to advertise goes away. getaddrinfo can do everything a DNS64 nameserver does. Add AI_DNS64MAPPED to getaddrinfo and the application can make a choice about whether it wants to see DNS64 mapped address or not. Make AI_DNS64MAPPED part of the default set of flags. Applications that don't want mapped addresses can then turn it off on a per call basis. flags = AI_DEFAULT; #ifdef AI_DNS64MAPPED flags &= ~AI_DNS64MAPPED; #endif I'm fine with making the end stage work well. Just stop trying to do "no changes to the nodes" as it will not work and is a waste of everbody's time. DNS64 as we have it is good enough for the stop gap stage. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dthaler@microsoft.com Thu Nov 10 07:30:53 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284D421F8B06 for ; Thu, 10 Nov 2011 07:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.605 X-Spam-Level: X-Spam-Status: No, score=-110.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FPmVYN+fg2R for ; Thu, 10 Nov 2011 07:30:52 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBC621F8AFB for ; Thu, 10 Nov 2011 07:30:52 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Nov 2011 07:30:52 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 10 Nov 2011 07:30:52 -0800 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.162]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0355.003; Thu, 10 Nov 2011 07:30:51 -0800 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Comments on draft-sivakumar-behave-nat-logging-03 Thread-Index: AcyfW5BCln8kX3wLSUicEd9FWWl3jQ== Date: Thu, 10 Nov 2011 15:30:51 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B2E9B35@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 15:30:53 -0000 1) The abstract says: > The lack of a consistent way makes it difficult to write > the collector applications that would receive this data and process > it to present useful information. =20 However the document only discusses data objects not a specific mechanism to retrieve them. As such, the statement above is still true because there's no consistent way to receive such data. So what problem is this trying to solve? And is it useful without=20 specifying what protocol to use? 2) Section 1 says: > The usage of the term "NAT device" in this document refer to any > NAT44, Firewall and NAT64 devices. =20 The term NAT64 by itself includes both stateful NAT64 and stateless NAT64. Why would logging be required for stateless devices? Furthermore, the abstract talks about CGNs (where logging makes sense). Why would the requirements in this document apply to "any" device (as opposed to only CGNs) including CPE home gateways? I didn't see any text discussing or justifying this statement. If this really is just about logging requirements for CGNs then this should be discussed in the context of the CGN requirements document. 3) The document uses several terms without defining them: "template", "address realm", "VRF", "NAT session", etc. =20 4) Section 4 says: > Prior to logging any events, the NAT device MUST send the template of > the record to the collector to declare the format of the data record > that it is using to send the events. The above MUST might make sense for a specific protocol, but since this document currently doesn't require any specific protocol the MUST doesn't make sense. For example, if the protocol is SNMP Traps or InformRequests, then the format is specified in a MIB and there's no need for the NAT device to send it a MIB. Similarly for any other protoco= l the collector might have some other way of getting the template from=20 somewhere other than the NAT device. 5) Section 4.1-4.3: Some of these seem underspecified by comparison to what I'm used to in MIBs. (e.g., what's the format of "timestamp"? what are the units? since when? Local time or UTC?) This would be cleaner if done in some formal way like SMIv2 or whatever, which can reference well-defined data types. And then no new "NAT Event Logging" registry would be=20 needed from IANA either. 6) Section 4.1: This defines "MAC address" as 48 bits which is too link-type specific. A generic document that claims to apply to "any NAT device" should be link-type agnostic. (Same comment goes for "VLAN ID".) 7) Section 4.3.11: The text confuses "user" with "source address". They're not the same thing= . There can be many users per source address, as well as multiple source addresses per user. -Dave From ssenthil@cisco.com Thu Nov 10 10:55:41 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213FE21F8B82 for ; Thu, 10 Nov 2011 10:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NniyfOZF4-7f for ; Thu, 10 Nov 2011 10:55:39 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3B84A21F8B7A for ; Thu, 10 Nov 2011 10:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=4515; q=dns/txt; s=iport; t=1320951339; x=1322160939; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=K5p0N/ir+x0TThdp/VwuaWv1JRbPMOS/M7nOT3vzkhE=; b=fZkuwgmGKL3vLVoIdslScGSOYvfGzHWzXrUVr615oCrnLBE9UlyktvVF vYbjX3SoNfn8kuLXV+DQo02Kod4Dp6wa6fP1GEq+qYqm83fLAWc3tVgnW kKQ9S1k/N9hp1ylB7nFLtG04qwntuqagdh+bgIwoSt6dIjBtNUe8n/IuP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOAdvE6rRDoG/2dsb2JhbABEqiyBBYFyAQEBAwEBAQEPAScCATEQDQEICQVfMAEBBAESIodgCJk7AZ5gBIZPgy8EiA+EeYcghUGMUg X-IronPort-AV: E=Sophos;i="4.69,489,1315180800"; d="scan'208";a="13501046" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 10 Nov 2011 18:55:21 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAAItLCb014498; Thu, 10 Nov 2011 18:55:21 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 10:55:21 -0800 Received: from 10.82.247.142 ([10.82.247.142]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 Nov 2011 18:55:20 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Thu, 10 Nov 2011 13:55:18 -0500 From: ssenthil To: Dave Thaler , "behave@ietf.org" Message-ID: Thread-Topic: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03 Thread-Index: AcyfW5BCln8kX3wLSUicEd9FWWl3jQAfrm8O In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B2E9B35@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Nov 2011 18:55:21.0174 (UTC) FILETIME=[4BE2BF60:01CC9FDA] Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 18:55:41 -0000 Thanks for the comments. Please see inline On 11/10/11 10:30 AM, "Dave Thaler" wrote: > 1) The abstract says: >> The lack of a consistent way makes it difficult to write >> the collector applications that would receive this data and process >> it to present useful information. > > However the document only discusses data objects not a specific > mechanism to retrieve them. As such, the statement above is still > true because there's no consistent way to receive such data. > So what problem is this trying to solve? And is it useful without > specifying what protocol to use? The problem we are trying to solve is as specified above, to be able to write applications that can collect and process them without having to deal with vendor specific implementations. I believe trying to specify the protocol to use to transport the data objects is beyond the scope of this specification. We could recommend some protocol if that would make this specification complete. > > 2) Section 1 says: >> The usage of the term "NAT device" in this document refer to any >> NAT44, Firewall and NAT64 devices. > > The term NAT64 by itself includes both stateful NAT64 and stateless NAT64. > Why would logging be required for stateless devices? > Furthermore, the abstract talks about CGNs (where logging makes sense). > Why would the requirements in this document apply to "any" device (as > opposed to only CGNs) including CPE home gateways? I didn't see any > text discussing or justifying this statement. > If this really is just about logging requirements for CGNs then this should > be discussed in the context of the CGN requirements document. Some NATs might not require it - like CPEs, but there are NATs deployed in enterprises too (they don't have to come under the CGN umbrella) and that would still require a logging function. > > 3) The document uses several terms without defining them: > "template", "address realm", "VRF", "NAT session", etc. > Ok, I will address them in the next revision. > 4) Section 4 says: >> Prior to logging any events, the NAT device MUST send the template of >> the record to the collector to declare the format of the data record >> that it is using to send the events. > > The above MUST might make sense for a specific protocol, but since this > document currently doesn't require any specific protocol the MUST doesn't > make sense. For example, if the protocol is SNMP Traps or InformRequests, > then the format is specified in a MIB and there's no > need for the NAT device to send it a MIB. Similarly for any other protocol > the collector might have some other way of getting the template from > somewhere other than the NAT device. > I am not sure I see the connection between the protocol specification and the ability to send templates. The reason for sending the template is that the same device could be sending multiple templates (one for nat44 create event and the other for NAT64 delete event and another for a NAT44 quota exceeded event. All of them carry different data sets and hence the template is necessary. > 5) Section 4.1-4.3: > Some of these seem underspecified by comparison to what I'm used to > in MIBs. (e.g., what's the format of "timestamp"? what are the units? > since when? Local time or UTC?) This would be cleaner if done in some > formal way like SMIv2 or whatever, which can reference well-defined > data types. And then no new "NAT Event Logging" registry would be > needed from IANA either. > Ok. But for NAT specific types like a translatedAddress and port those types have to be defined. > 6) Section 4.1: > This defines "MAC address" as 48 bits which is too link-type specific. > A generic document that claims to apply to "any NAT device" > should be link-type agnostic. (Same comment goes for "VLAN ID".) > > 7) Section 4.3.11: > The text confuses "user" with "source address". They're not the same thing. > There can be many users per source address, as well as multiple source > addresses per user. > If I reword this as follows, would that be better? "The examples of Quota exceeded are to allow only certain number of NAT sessions per device, certain number of NAT sessions per subscriber etc." Thanks Senthil > -Dave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dthaler@microsoft.com Thu Nov 10 14:58:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB641F0C50 for ; Thu, 10 Nov 2011 14:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.605 X-Spam-Level: X-Spam-Status: No, score=-110.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaSAQG1eKBNB for ; Thu, 10 Nov 2011 14:58:11 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7941F0C51 for ; Thu, 10 Nov 2011 14:58:11 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Nov 2011 14:58:11 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 10 Nov 2011 14:58:11 -0800 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.162]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0355.003; Thu, 10 Nov 2011 14:58:10 -0800 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Comments on draft-ietf-behave-lsn-requirements-04 Thread-Index: AcyfZJ0jKsKRsEeQTx+gGCs+jQvTyAAl48WQ Date: Thu, 10 Nov 2011 22:58:10 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B2EACB5@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Comments on draft-ietf-behave-lsn-requirements-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 22:58:12 -0000 Summary: 1) REQ-7 has the clause 'UNLESS it is known that "Address- Independent Filt= ering" does not cause the application-layer protocol to break'. =20 Not sure this makes sense. How could it reliably know the application-layer= protocol?=20 Since this is already a "RECOMMENDED" not a MUST, I think this phrase shoul= d be deleted. 2) REQ-12 is about DSCP values. Why is this requirement specific to CGNs (rather than all NATs)? It also contains two sentences that seem to contr= adict each other: > When packets pass from one side to the other, the DSCP values MUST be=20 > preserved. If the CGN also includes diffserv classifier and marker=20 > functionality it MAY change the DSCP values. Because of the MAY in the second sentence, s/MUST/SHOULD/ If there is a reason this belongs in this document because there's somethin= g specific to CGNs, then the Justification should explain it. 3) Any mention of "NAT444" seems irrelevant. Suggest removing all use of = that term. 4) Several items (e.g., sections 4, 4.1, 8) use RFC 2119 language without u= sing the REQ-# format and should be recast into that format. 5) Section 5 seems to have no requirements, so why is it in this document? If there are requirements (and I suspect there are), then they should be ca= lled out. Same for section 6. 6) A couple places phrase requirements in terms of what an administrator do= es. These should be rephrased as CGN implementation requirements (e.g., being c= apable of being configured to do blah). Examples of such statements are in= section 8 and in the second sentence of REQ-2. I'll send a marked up PDF to the authors with in-line comments/edits that i= nclude various editorial nits. -Dave From dthaler@microsoft.com Thu Nov 10 15:16:59 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749FA21F8AF4 for ; Thu, 10 Nov 2011 15:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.605 X-Spam-Level: X-Spam-Status: No, score=-110.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKT++8jbDypp for ; Thu, 10 Nov 2011 15:16:58 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0821F87D9 for ; Thu, 10 Nov 2011 15:16:58 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Nov 2011 15:16:58 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 10 Nov 2011 15:16:58 -0800 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.162]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0355.003; Thu, 10 Nov 2011 15:16:58 -0800 From: Dave Thaler To: ssenthil , "behave@ietf.org" Thread-Topic: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03 Thread-Index: AcyfW5BCln8kX3wLSUicEd9FWWl3jQAfrm8OAAjyqmA= Date: Thu, 10 Nov 2011 23:16:56 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B2EBF5A@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B2E9B35@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 23:16:59 -0000 Ssenthil writes:=20 > > 1) The abstract says: > >> The lack of a consistent way makes it difficult to write the > >> collector applications that would receive this data and process it to > >> present useful information. > > > > However the document only discusses data objects not a specific > > mechanism to retrieve them. As such, the statement above is still > > true because there's no consistent way to receive such data. > > So what problem is this trying to solve? And is it useful without > > specifying what protocol to use? >=20 > The problem we are trying to solve is as specified above, to be able to w= rite > applications that can collect and process them without having to deal wit= h > vendor specific implementations. I believe trying to specify the protocol= to > use to transport the data objects is beyond the scope of this specificati= on. > We could recommend some protocol if that would make this specification > complete. This draft does not currently allow you to write apps that collect and proc= ess them without having to deal with vendor specific implementations. To get that, you'd have to specify what protocol to use. Otherwise you have to deal with vendor specific protocol code anyway so you haven't met your stated goal. > > 2) Section 1 says: > >> The usage of the term "NAT device" in this document refer to any > >> NAT44, Firewall and NAT64 devices. > > > > The term NAT64 by itself includes both stateful NAT64 and stateless > NAT64. > > Why would logging be required for stateless devices? > > Furthermore, the abstract talks about CGNs (where logging makes sense). > > Why would the requirements in this document apply to "any" device (as > > opposed to only CGNs) including CPE home gateways? I didn't see any > > text discussing or justifying this statement. > > If this really is just about logging requirements for CGNs then this > > should be discussed in the context of the CGN requirements document. >=20 > Some NATs might not require it - like CPEs, but there are NATs deployed i= n > enterprises too (they don't have to come under the CGN umbrella) and that > would still require a logging function. Ok. Since you agree that this does not apply to "any" device, I expect you will update the text accordingly. [...] > > 4) Section 4 says: > >> Prior to logging any events, the NAT device MUST send the template > >> of the record to the collector to declare the format of the data > >> record that it is using to send the events. > > > > The above MUST might make sense for a specific protocol, but since > > this document currently doesn't require any specific protocol the MUST > doesn't > > make sense. For example, if the protocol is SNMP Traps or > InformRequests, > > then the format is specified in a MIB and there's no > > need for the NAT device to send it a MIB. Similarly for any other pro= tocol > > the collector might have some other way of getting the template from > > somewhere other than the NAT device. >=20 > I am not sure I see the connection between the protocol specification and > the ability to send templates. The reason for sending the template is tha= t > the same device could be sending multiple templates (one for nat44 create > event and the other for NAT64 delete event and another for a NAT44 quota > exceeded event. All of them carry different data sets and hence the templ= ate > is necessary. I understand you didn't follow what I said, so I'll try to rephrase. A NAT device can send all of this information to a collector without sending any= =20 "template" before sending the information. Of course since you never defi= ned the term template, I'm assuming it means schema. The collector might alre= ady have the templates, and there's many examples of this today. [...] > > 7) Section 4.3.11: > > The text confuses "user" with "source address". They're not the same > thing. > > There can be many users per source address, as well as multiple source > > addresses per user. > > > If I reword this as follows, would that be better? >=20 > "The examples of Quota exceeded are to allow only certain number of NAT > sessions per device, certain number of NAT sessions per subscriber etc." Yes that's much better. -Dave=20 From cathryn@infc.ulst.ac.uk Fri Nov 11 01:14:38 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5442F21F8888 for ; Fri, 11 Nov 2011 01:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOHuEJfCBgY0 for ; Fri, 11 Nov 2011 01:14:38 -0800 (PST) Received: from e4.ulster.ac.uk (e4.ulster.ac.uk [194.80.87.111]) by ietfa.amsl.com (Postfix) with ESMTP id BAF8721F886A for ; Fri, 11 Nov 2011 01:14:34 -0800 (PST) Received: from m0.ulster.ac.uk (m0.ulster.ac.uk [194.80.87.153]) by e4.ulster.ac.uk (UU/BC) with ESMTP id pAB9EX6X029470 for ; Fri, 11 Nov 2011 09:14:33 GMT Received: from martello.infc.ulst.ac.uk (martello.infc.ulst.ac.uk [193.61.166.223]) by m0.ulster.ac.uk (UU/BC) with ESMTP id pAB9EXGU006995 for ; Fri, 11 Nov 2011 09:14:33 GMT (envelope-from cathryn@infc.ulst.ac.uk) Received: from localhost (localhost.localdomain [127.0.0.1]) by martello.infc.ulst.ac.uk (Postfix) with ESMTP id BFD7A3D067C for ; Fri, 11 Nov 2011 09:14:33 +0000 (GMT) X-Virus-Scanned: amavisd-new at martello.infc.ulst.ac.uk Received: from martello.infc.ulst.ac.uk ([127.0.0.1]) by localhost (martello.infc.ulst.ac.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DioukeK6Q7H for ; Fri, 11 Nov 2011 09:14:33 +0000 (GMT) Received: from martello.infc.ulst.ac.uk (martello.infc.ulst.ac.uk [193.61.166.223]) by martello.infc.ulst.ac.uk (Postfix) with ESMTP id A57AE3D05BD for ; Fri, 11 Nov 2011 09:14:33 +0000 (GMT) Date: Fri, 11 Nov 2011 09:14:33 +0000 (GMT) From: "Peoples, Cathryn" To: Behave@ietf.org Message-ID: <417225282.711321002873575.JavaMail.root@martello.infc.ulst.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [193.61.166.86] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL5_64 (ZimbraWebClient - SAF3 (Win)/5.0.18_GA_3011.RHEL5_64) Subject: [BEHAVE] [CfP] IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) - April 16, 2012 - Maui, Hawaii, USA X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 09:14:38 -0000 ----------------------------------------------------------------------------------------------------- Please accept our apologies if you receive multiple copies of this CfP ----------------------------------------------------------------------------------------------------- IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) ================================================================================== 16 April 2012 Maui, Hawaii, USA http://www.manfi.org CALL FOR PAPERS --------------- The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network Operations and Management (CNOM). It is widely agreed that, despite its many successes, the current Internet also has a set of systemic problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack of scalable and agile manageability is arguably more important, as without management, it is impossible to build systems that adapt the services and resources offered in a context-dependent manner. In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future Internet from the beginning. Following the success of the three previous editions of this workshop, held in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this challenging topic. Topics of interest ------------------ Authors are invited to submit papers that fall into or are related to the topic areas listed below: - Architectural Issues * Advantages and disadvantages of revolutionary, evolutionary, and other approaches to managing the Future Internet * Separation of data, control, and management planes * Design of architectural building blocks for managing the Future Internet * Advances in measurement, management, security, accounting, mobility, and other functions * Virtualization of resources and services * Dynamic composition of management and operational functionality * Mechanisms for managing interconnected computational infrastructures (e.g. elastic clouds, federated clouds) in the Future Internet * Implications of social network success on the Future Internet architecture - Design and Implementation Issues * Abstractions for programmable network elements * Accommodating context-awareness in management * Applying situation awareness to network management * Federation between administrative domains and support of all constituencies * The role of models, ontologies, and other knowledge abstractions in the Future Internet * Uncertainty and probabilistic approaches to management of the Future Internet * Approaches for the organization of management data, data analytics and visualization * Experience reports from Future Internet experimental facilities set-up and results - Economic Issues * Economic aspects driving the deployment of Future Internet management technology * Economic opportunities and challenges for management technology * Experience reports from management in test beds Paper submission ---------------- Paper submissions must present original, research or experiences. Late-breaking advances and work-in-progress reports from ongoing research are also encouraged. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 word abstract that clearly outlines the scope and contributions of the paper, and a list of up to 5 key words. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular conference papers, and 4 pages for short papers. Submissions must be in IEEE 2-column style. Papers exceeding these limits, multiple submissions, and self-plagiarized papers will be rejected without further review. Authors should submit their papers in PDF, postscript, or Word formats via JEMS: (https://submissoes.sbc.org.br/). Proceedings ----------- Papers accepted for ManFI 2012 will be included in the conference proceedings, IEEE Xplore, and EI Index. The IEEE reserves the right to remove any paper from IEEE Xplore if the paper is not presented at the workshop. Awards will be presented to the best paper and to the best student paper at the workshop. Furthermore, we plan to work with a leading journal, such as JNSM, TNSM and IJNM, to solicit extended versions of the best papers of ManFI 2012 to be submitted for review. Workshop Co-Chairs ------------------ - Prof. James Won-Ki Hong, POSTECH, Korea - Prof. Filip De Turck, Ghent University - IBBT, Belgium - Dr. Yoshiaki Kiriha, NEC, Japan - Dr. Sven van der Meer, Ericsson LM, Ireland Publicity Co-Chairs ------------------- - Leonidas Lymberopoulos, National Technical University of Athens, Greece - Cathryn Peoples, University of Ulster, UK Important dates --------------- - Abstract registration deadline: December 14, 2011 - Paper submission: December 20, 2011 - Notification of acceptance: January 31, 2012 - Final version of papers due: February 15, 2012 - Workshop date: April 16, 2012 For more information, please contact one of the Workshop Co-Chairs at tpcchairs@manfi2012.org From simon.perreault@viagenie.ca Fri Nov 11 06:46:05 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8D521F85AE for ; Fri, 11 Nov 2011 06:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfxeJJ6FZ72h for ; Fri, 11 Nov 2011 06:46:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id A5EC721F85AA for ; Fri, 11 Nov 2011 06:46:04 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0A58F20D35 for ; Fri, 11 Nov 2011 09:45:33 -0500 (EST) Message-ID: <4EBD350D.7050905@viagenie.ca> Date: Fri, 11 Nov 2011 09:45:33 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <9B57C850BB53634CACEC56EF4853FF653B2EACB5@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B2EACB5@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Comments on draft-ietf-behave-lsn-requirements-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 14:46:05 -0000 On 11/10/2011 05:58 PM, Dave Thaler wrote: > 1) REQ-7 has the clause 'UNLESS it is known that "Address- Independent Filtering" > does not cause the application-layer protocol to break'. > Not sure this makes sense. How could it reliably know the application-layer protocol? That is intentionally left unspecified. Otherwise it's a rat hole. > Since this is already a "RECOMMENDED" not a MUST, I think this phrase should be deleted. Well, that's the point of using the "RECOMMENDED ... UNLESS" idiom: to provide guidance as to when it is acceptable to deviate from the recommendation. > 2) REQ-12 is about DSCP values. Why is this requirement specific to CGNs > (rather than all NATs)? Right, I don't think it's specific to CGNs. How about we move it to draft-penno-behave-rfc4787-5382-5508-bis? > It also contains two sentences that seem to contradict each > other: >> When packets pass from one side to the other, the DSCP values MUST be >> preserved. If the CGN also includes diffserv classifier and marker >> functionality it MAY change the DSCP values. > > Because of the MAY in the second sentence, s/MUST/SHOULD/ Agreed. I'll use the "SHOULD ... UNLESS" idiom. > 3) Any mention of "NAT444" seems irrelevant. Suggest removing all use of that term. Agreed. > 4) Several items (e.g., sections 4, 4.1, 8) use RFC 2119 language without using the REQ-# format and should be recast into that format. Makes sense. > 5) Section 5 seems to have no requirements, so why is it in this document? > If there are requirements (and I suspect there are), then they should be called out. > Same for section 6. They are informational. The intent is to provide guidance to CGN implementers. I think it makes sense to keep them. We could explicitly state that these sections are not normative. What is it that is bugging you exactly? > 6) A couple places phrase requirements in terms of what an administrator does. > These should be rephrased as CGN implementation requirements (e.g., being capable of being configured to do blah). Examples of such statements are in section 8 and in the second sentence of REQ-2. Makes sense. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From haibin.song@huawei.com Thu Nov 10 17:26:02 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D485321F8586; Thu, 10 Nov 2011 17:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.025 X-Spam-Level: X-Spam-Status: No, score=-6.025 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D78aYLds4blT; Thu, 10 Nov 2011 17:26:02 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9D521F856F; Thu, 10 Nov 2011 17:26:02 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUH00I1J2N6O5@szxga03-in.huawei.com>; Fri, 11 Nov 2011 09:25:55 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUH00C2J2N64X@szxga03-in.huawei.com>; Fri, 11 Nov 2011 09:25:54 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEX35792; Fri, 11 Nov 2011 09:25:54 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 11 Nov 2011 09:25:47 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.229]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Fri, 11 Nov 2011 09:25:47 +0800 Date: Fri, 11 Nov 2011 01:18:51 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.129] To: jouni korhonen Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [BEHAVE] tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01 Thread-index: AQHMnfxfCPV3kDN/y0GD4t+CTL/BI5Wm5ROw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: X-Mailman-Approved-At: Fri, 11 Nov 2011 08:40:12 -0800 Cc: Behave WG , "tsv-ads@ietf.org" , "draft-ietf-behave-nat64-learn--analysis@tools.ietf.org" , TSV Dir Subject: Re: [BEHAVE] tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 01:26:02 -0000 Hi Jouni, > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com] > Sent: Tuesday, November 08, 2011 5:52 PM > To: Songhaibin > Cc: draft-ietf-behave-nat64-learn--analysis@tools.ietf.org; Behave WG; > tsv-ads@ietf.org; TSV Dir > Subject: Re: [BEHAVE] tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01 > > Hi Haibin, > > Thank you for the review. See my comments inline. > > On Nov 6, 2011, at 4:17 AM, Songhaibin wrote: > > > Hello, > > > > I've reviewed this document as part of the transport area directorate's ongoing > effort to review key IETF documents. These comments were written primarily for > the transport area directors, but are copied to the document's authors for their > information and to allow them to address any issues raised. The authors should > consider this review together with any other last-call comments they receive. > Please always CC tsv-dir@ietf.org if you reply to or forward this review. > > > > SUMMARY > > > > This draft is basically ready for publication, but has nits that should be fixed > before publication. > > > > > > One comment: > > > > In section 5 (Conclusion), it compares DHCP/RA like solutions to DNS like > solutions, and gives the recommendation of using DNS method, but without > comparing that with STUN like methods. Is it possible to add it or people think > there is obvious reason (DNS is better than STUN)? > > Good point. We should add some text along lines: "a host does not need to > implement STUN where as DNS is in practice required anyway. Also, STUN > protocol would be needed to changed on both host and network side to support > the discovery of NAT64". > > Would that work for you? > The text looks good to me. > > > > > Another minor comment: > > > > In section 4.6.1 , [I-D.boucadair-dhcpv6-shared-address-option] also support > NAT64 prefix allocation for building IPv4-embedded IPv6 address using DHCPv6 > option. And this should be mentioned in the document. > > Ok. Will add this. > Then I am okay with this draft. Thanks, -Haibin > Thanks, > Jouni > > > > > > > > BR, > > -Haibin > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave From jouni.nospam@gmail.com Sat Nov 12 00:33:44 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B439B21F848A for ; Sat, 12 Nov 2011 00:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVQLsL9xy+Nw for ; Sat, 12 Nov 2011 00:33:44 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1148821F8486 for ; Sat, 12 Nov 2011 00:33:43 -0800 (PST) Received: by yenq4 with SMTP id q4so1788244yen.31 for ; Sat, 12 Nov 2011 00:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cXknIU9SO8e7WkwlQ83VcJLPXzDydHD3nfVlNbk3M40=; b=eIktCIakywuXpVrsmHWNo/us1oMtwFQ3U+vkLP4IKzTDV4oAEyFgosVXJkuP1M+miM aOt6Msjgrm0yJTuvxu7WxnolOYwjzLP+Kp+fr/d6yp3lnk0Xm+9DtfRjwRMzE/P5kIk8 ErIg/blz9bKtVIe+XRQrNPpb52dOray/+MPIQ= Received: by 10.68.16.3 with SMTP id b3mr30856053pbd.86.1321086821684; Sat, 12 Nov 2011 00:33:41 -0800 (PST) Received: from n219076092116.netvigator.com (n219076092116.netvigator.com. [219.76.92.116]) by mx.google.com with ESMTPS id jm5sm37265320pbc.1.2011.11.12.00.33.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Nov 2011 00:33:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <20111109224556.AC24116F9B60@drugs.dv.isc.org> Date: Sat, 12 Nov 2011 10:33:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB9E1E0.1070501@gmail.com> <4EBADA4B.7010603@gmail.com> <20111109224556.AC24116F9B60@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1084) Cc: Stephan Lagerholm , behave@ietf.org, Andrew Sullivan Subject: Re: [BEHAVE] DNS64 detecting dual stack clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 08:33:44 -0000 [snip] > Move the DNS64 re-writing into the nodes and the whole issues of > which type of DNS server to advertise goes away. getaddrinfo can > do everything a DNS64 nameserver does. Add AI_DNS64MAPPED to > getaddrinfo and the application can make a choice about whether it > wants to see DNS64 mapped address or not. Make AI_DNS64MAPPED part > of the default set of flags. >=20 > Applications that don't want mapped addresses can then turn it off > on a per call basis. >=20 > flags =3D AI_DEFAULT; > #ifdef AI_DNS64MAPPED > flags &=3D ~AI_DNS64MAPPED; > #endif >=20 > I'm fine with making the end stage work well. Just stop trying to > do "no changes to the nodes" as it will not work and is a waste of > everbody's time. DNS64 as we have it is good enough for the stop > gap stage. This was basically the implementation we had (along with EDNS0 option = for synthesized pref64 length) in our getaddrinfo() when we experimented = with draft-korhonen-edns0-synthesis-flag-02.=20 - JOuni >=20 > Mark > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From marka@isc.org Sat Nov 12 00:56:45 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B8721F84BD for ; Sat, 12 Nov 2011 00:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzC37z8U4sR0 for ; Sat, 12 Nov 2011 00:56:45 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2382721F848C for ; Sat, 12 Nov 2011 00:56:45 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 304145F9891; Sat, 12 Nov 2011 08:56:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DB01E216C86; Sat, 12 Nov 2011 08:55:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B13421711706; Sat, 12 Nov 2011 19:55:56 +1100 (EST) To: jouni korhonen From: Mark Andrews References: <4EB9E1E0.1070501@gmail.com> <4EBADA4B.7010603@gmail.com> <20111109224556.AC24116F9B60@drugs.dv.isc.org> In-reply-to: Your message of "Sat, 12 Nov 2011 10:33:37 +0200." Date: Sat, 12 Nov 2011 19:55:56 +1100 Message-Id: <20111112085556.B13421711706@drugs.dv.isc.org> Cc: Stephan Lagerholm , behave@ietf.org, Andrew Sullivan Subject: Re: [BEHAVE] DNS64 detecting dual stack clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 08:56:45 -0000 In message , jouni korhonen writes: > > > [snip] > > > > Move the DNS64 re-writing into the nodes and the whole issues of > > which type of DNS server to advertise goes away. getaddrinfo can > > do everything a DNS64 nameserver does. Add AI_DNS64MAPPED to > > getaddrinfo and the application can make a choice about whether it > > wants to see DNS64 mapped address or not. Make AI_DNS64MAPPED part > > of the default set of flags. > >=20 > > Applications that don't want mapped addresses can then turn it off > > on a per call basis. > >=20 > > flags =3D AI_DEFAULT; > > #ifdef AI_DNS64MAPPED > > flags &=3D ~AI_DNS64MAPPED; > > #endif > >=20 > > I'm fine with making the end stage work well. Just stop trying to > > do "no changes to the nodes" as it will not work and is a waste of > > everbody's time. DNS64 as we have it is good enough for the stop > > gap stage. > > This was basically the implementation we had (along with EDNS0 option = > for synthesized pref64 length) in our getaddrinfo() when we experimented = > with draft-korhonen-edns0-synthesis-flag-02.=20 > > - JOuni And it has the advantage that you can use getaddrinfo for handling literal IPv4 address. > >=20 > > Mark > > --=20 > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rpenno@juniper.net Sat Nov 12 13:24:00 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EF721F8801 for ; Sat, 12 Nov 2011 13:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65MQytxCQZyT for ; Sat, 12 Nov 2011 13:24:00 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id E31F621F87C2 for ; Sat, 12 Nov 2011 13:23:58 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTr7j36vKTZQbokY+LsBIiL5ALRSI182g@postini.com; Sat, 12 Nov 2011 13:23:59 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 12 Nov 2011 13:23:39 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sat, 12 Nov 2011 16:23:38 -0500 From: Reinaldo Penno To: Simon Perreault , "behave@ietf.org" Date: Sat, 12 Nov 2011 16:23:36 -0500 Thread-Topic: [BEHAVE] Comments on draft-ietf-behave-lsn-requirements-04 Thread-Index: AcyggKqph5fIfXqfTiywlEtJEqh4fwBAKvET Message-ID: In-Reply-To: <4EBD350D.7050905@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on draft-ietf-behave-lsn-requirements-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 21:24:00 -0000 I can incorporate into the next version draft-penno-behave-rfc4787-5382-5508-bis On 11/11/11 6:45 AM, "Simon Perreault" wrote: >> 2) REQ-12 is about DSCP values. Why is this requirement specific to CGN= s >> (rather than all NATs)? >=20 > Right, I don't think it's specific to CGNs. How about we move it to > draft-penno-behave-rfc4787-5382-5508-bis? From ssenthil@cisco.com Sat Nov 12 17:35:06 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F3011E8082 for ; Sat, 12 Nov 2011 17:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUC-zPuueXAQ for ; Sat, 12 Nov 2011 17:35:05 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 60A2421F8ACE for ; Sat, 12 Nov 2011 17:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=4784; q=dns/txt; s=iport; t=1321148104; x=1322357704; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=x3+YeM3shtbuxzVnit5/iy8Dio+4jqikmRBa5hSq1Ek=; b=NHJclchV8050SHSyQ2LmIT4r8FuD2zyM5K1TpT64MBsswVrRmKwU7ZGe 8q7ScmEJRy48xUX0Tck2MC1xehGh3rSA7weiFVZoQ1C/PwOLqA+J4H26r qR3Wh/rIE0vfxeYwNn1JAAYNRvwnKiXX9glzrp9UFq7K3ssTKLP5JCew0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKwdv06rRDoJ/2dsb2JhbABCqi+BBYFyAQEBAwESAScCAUENAQgJBYEPAQEEARIih2CYGwGdLIZPgzAEiBCEfIcihUSMUw X-IronPort-AV: E=Sophos;i="4.69,501,1315180800"; d="scan'208";a="13899397" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 13 Nov 2011 01:35:03 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAD1Z3dU018877; Sun, 13 Nov 2011 01:35:03 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Nov 2011 17:35:03 -0800 Received: from 10.82.235.157 ([10.82.235.157]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ; Sun, 13 Nov 2011 01:35:02 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Sat, 12 Nov 2011 20:35:00 -0500 From: ssenthil To: Dave Thaler , "behave@ietf.org" Message-ID: Thread-Topic: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03 Thread-Index: AcyfW5BCln8kX3wLSUicEd9FWWl3jQAfrm8OAAjyqmAAaZgjKw== In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B2EBF5A@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Nov 2011 01:35:03.0128 (UTC) FILETIME=[77120580:01CCA1A4] Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 01:35:06 -0000 On 11/10/11 6:16 PM, "Dave Thaler" wrote: > Ssenthil writes: >>> 1) The abstract says: >>>> The lack of a consistent way makes it difficult to write the >>>> collector applications that would receive this data and process it to >>>> present useful information. >>> >>> However the document only discusses data objects not a specific >>> mechanism to retrieve them. As such, the statement above is still >>> true because there's no consistent way to receive such data. >>> So what problem is this trying to solve? And is it useful without >>> specifying what protocol to use? >> >> The problem we are trying to solve is as specified above, to be able to write >> applications that can collect and process them without having to deal with >> vendor specific implementations. I believe trying to specify the protocol to >> use to transport the data objects is beyond the scope of this specification. >> We could recommend some protocol if that would make this specification >> complete. > > This draft does not currently allow you to write apps that collect and process > them without having to deal with vendor specific implementations. To get > that, you'd have to specify what protocol to use. Otherwise you have to > deal with vendor specific protocol code anyway so you haven't met your > stated goal. There are many choices of the protocol that can be used to transport the data. But we wanted to stay away from getting into exact recommendation of the protocol to use. > >>> 2) Section 1 says: >>>> The usage of the term "NAT device" in this document refer to any >>>> NAT44, Firewall and NAT64 devices. >>> >>> The term NAT64 by itself includes both stateful NAT64 and stateless >> NAT64. >>> Why would logging be required for stateless devices? >>> Furthermore, the abstract talks about CGNs (where logging makes sense). >>> Why would the requirements in this document apply to "any" device (as >>> opposed to only CGNs) including CPE home gateways? I didn't see any >>> text discussing or justifying this statement. >>> If this really is just about logging requirements for CGNs then this >>> should be discussed in the context of the CGN requirements document. >> >> Some NATs might not require it - like CPEs, but there are NATs deployed in >> enterprises too (they don't have to come under the CGN umbrella) and that >> would still require a logging function. > > Ok. Since you agree that this does not apply to "any" device, I expect you > will update the text accordingly. > > [...] Ok I will change the text to reflect that it is not a must for all kinds of NAT. > >>> 4) Section 4 says: >>>> Prior to logging any events, the NAT device MUST send the template >>>> of the record to the collector to declare the format of the data >>>> record that it is using to send the events. >>> >>> The above MUST might make sense for a specific protocol, but since >>> this document currently doesn't require any specific protocol the MUST >> doesn't >>> make sense. For example, if the protocol is SNMP Traps or >> InformRequests, >>> then the format is specified in a MIB and there's no >>> need for the NAT device to send it a MIB. Similarly for any other protocol >>> the collector might have some other way of getting the template from >>> somewhere other than the NAT device. >> >> I am not sure I see the connection between the protocol specification and >> the ability to send templates. The reason for sending the template is that >> the same device could be sending multiple templates (one for nat44 create >> event and the other for NAT64 delete event and another for a NAT44 quota >> exceeded event. All of them carry different data sets and hence the template >> is necessary. > > I understand you didn't follow what I said, so I'll try to rephrase. A NAT > device can send all of this information to a collector without sending any > "template" before sending the information. Of course since you never defined > the term template, I'm assuming it means schema. The collector might already > have the templates, and there's many examples of this today. > I will define what a template is in the next rev. Yes, schema and template are the same. The problem with the fixed templates is that it makes it difficult to change and adopt to different implementations. Let me give you an example. If the schema/template changes the data to be exported for example an previously optional field now becomes a part of the new template, then the collector device need to change its template too. Having the templates sent over dynamically provides a much greater benefit and ability to change the schema. Senthil From dthaler@microsoft.com Sat Nov 12 18:31:04 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FF111E8089 for ; Sat, 12 Nov 2011 18:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.604 X-Spam-Level: X-Spam-Status: No, score=-110.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEsWGYZhFg6Q for ; Sat, 12 Nov 2011 18:31:03 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id CAA9E11E8083 for ; Sat, 12 Nov 2011 18:31:03 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 12 Nov 2011 18:31:03 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.355.3; Sat, 12 Nov 2011 18:31:03 -0800 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.162]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0355.003; Sat, 12 Nov 2011 18:31:03 -0800 From: Dave Thaler To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] Comments on draft-ietf-behave-lsn-requirements-04 Thread-Index: AcyfZJ0jKsKRsEeQTx+gGCs+jQvTyAAl48WQADHcpIAAOdd2MA== Date: Sun, 13 Nov 2011 02:31:02 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B2FE396@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B2EACB5@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4EBD350D.7050905@viagenie.ca> In-Reply-To: <4EBD350D.7050905@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on draft-ietf-behave-lsn-requirements-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 02:31:04 -0000 Simon Perreault wrote:=20 > On 11/10/2011 05:58 PM, Dave Thaler wrote: > > 1) REQ-7 has the clause 'UNLESS it is known that "Address- Independent > Filtering" > > does not cause the application-layer protocol to break'. > > Not sure this makes sense. How could it reliably know the application-l= ayer > protocol? >=20 > That is intentionally left unspecified. Otherwise it's a rat hole. >=20 > > Since this is already a "RECOMMENDED" not a MUST, I think this phrase > should be deleted. >=20 > Well, that's the point of using the "RECOMMENDED ... UNLESS" idiom: to > provide guidance as to when it is acceptable to deviate from the > recommendation. I agree it's a rat hole to even mention, but since you're mentioning it any= way you might be more explicit that it's not easy to know. Also UNLESS isn't a term defined in 2119 and shouldn't be capitalized. I'm not a fan of the "SHOULD ... unless" wording personally. Personally I think it's cleaner to either have "MUST ... if/unless" for things that ar= e conditionally mandatory, or for conditional recommendations then two separate sentences like "SHOULD blah. If blah, an implementation MAY instead do blah." > > 5) Section 5 seems to have no requirements, so why is it in this docume= nt? > > If there are requirements (and I suspect there are), then they should b= e > called out. > > Same for section 6. >=20 > They are informational. The intent is to provide guidance to CGN > implementers. I think it makes sense to keep them. We could explicitly st= ate > that these sections are not normative. What is it that is bugging you exa= ctly? We have an IPR declaration on a requirements document. That's surprising a= nd my guess is it's because the requirements document contains section 5 and 6 which aren't about requirements. -Dave From dthaler@microsoft.com Sat Nov 12 19:45:35 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2936A1F0C3E for ; Sat, 12 Nov 2011 19:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.604 X-Spam-Level: X-Spam-Status: No, score=-110.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH5LhRa53M3x for ; Sat, 12 Nov 2011 19:45:34 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 91ECE1F0C34 for ; Sat, 12 Nov 2011 19:45:34 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 12 Nov 2011 19:45:34 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.355.3; Sat, 12 Nov 2011 19:45:34 -0800 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.162]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0355.003; Sat, 12 Nov 2011 19:45:34 -0800 From: Dave Thaler To: ssenthil , "behave@ietf.org" Thread-Topic: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03 Thread-Index: AcyfW5BCln8kX3wLSUicEd9FWWl3jQAfrm8OAAjyqmAAaZgjKwAEF8Lw Date: Sun, 13 Nov 2011 03:45:33 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B2FF7C6@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B2EBF5A@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 03:45:35 -0000 > > This draft does not currently allow you to write apps that collect and > > process them without having to deal with vendor specific > > implementations. To get that, you'd have to specify what protocol to > > use. Otherwise you have to deal with vendor specific protocol code > > anyway so you haven't met your stated goal. >=20 > There are many choices of the protocol that can be used to transport the > data. But we wanted to stay away from getting into exact recommendation > of the protocol to use. Then you should change your goal. Personally I would be in favor of eithe= r of two approaches: a) be completely abstract, focus on requirements, and not protocol. This is what lsn-requirements draft does already. b) be concrete, specifying a solution for a particular protocol. Currently this draft does neither. It's halfway in between, which is the problem I have with it. > >>> 4) Section 4 says: > >>>> Prior to logging any events, the NAT device MUST send the template > >>>> of the record to the collector to declare the format of the data > >>>> record that it is using to send the events. > >>> > >>> The above MUST might make sense for a specific protocol, but since > >>> this document currently doesn't require any specific protocol the > >>> MUST > >> doesn't > >>> make sense. For example, if the protocol is SNMP Traps or > >> InformRequests, > >>> then the format is specified in a MIB and there's no > >>> need for the NAT device to send it a MIB. Similarly for any other > protocol > >>> the collector might have some other way of getting the template from > >>> somewhere other than the NAT device. > >> > >> I am not sure I see the connection between the protocol specification > >> and the ability to send templates. The reason for sending the > >> template is that the same device could be sending multiple templates > >> (one for nat44 create event and the other for NAT64 delete event and > >> another for a NAT44 quota exceeded event. All of them carry different > >> data sets and hence the template is necessary. > > > > I understand you didn't follow what I said, so I'll try to rephrase. > > A NAT device can send all of this information to a collector without > sending any > > "template" before sending the information. Of course since you never > defined > > the term template, I'm assuming it means schema. The collector might > already > > have the templates, and there's many examples of this today. > > > I will define what a template is in the next rev. Yes, schema and templat= e are > the same. The problem with the fixed templates is that it makes it diffic= ult to > change and adopt to different implementations. Let me give you an > example. > If the schema/template changes the data to be exported for example an > previously optional field now becomes a part of the new template, then th= e > collector device need to change its template too. Having the templates se= nt > over dynamically provides a much greater benefit and ability to change th= e > schema. Defining a "template" and sending it to the server is specifying part of a protocol (and would certainly not apply to some protocols) and is one of=20 the reasons this draft is not currently in category (a) as I defined it abo= ve. =20 Another reason where it is not abstract (i.e. not in category a) is that it defines bit lengths of data items. That implies that IP addresses and por= ts are sent in binary format, not in (say) string format, and hence is specify= ing part of a protocol. My recommendation would be to pick (a) or (b) and not try to be somewhere in between, which I find confusing. -Dave From simon.perreault@viagenie.ca Sat Nov 12 23:33:35 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0C111E80A0 for ; Sat, 12 Nov 2011 23:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrBrrmj2+aPF for ; Sat, 12 Nov 2011 23:33:34 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 856F111E8093 for ; Sat, 12 Nov 2011 23:33:34 -0800 (PST) Received: from banana.viagenie.ca (unknown [58.98.37.153]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 27A1F20D23; Sun, 13 Nov 2011 02:33:00 -0500 (EST) Message-ID: <4EBF72A9.8070403@viagenie.ca> Date: Sun, 13 Nov 2011 16:32:57 +0900 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Dave Thaler References: <9B57C850BB53634CACEC56EF4853FF653B2EACB5@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4EBD350D.7050905@viagenie.ca> <9B57C850BB53634CACEC56EF4853FF653B2FE396@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B2FE396@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Comments on draft-ietf-behave-lsn-requirements-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 07:33:35 -0000 Dave Thaler wrote, on 11/13/2011 11:31 AM: > Simon Perreault wrote: >> On 11/10/2011 05:58 PM, Dave Thaler wrote: >>> 1) REQ-7 has the clause 'UNLESS it is known that "Address- Independent >> Filtering" >>> does not cause the application-layer protocol to break'. >>> Not sure this makes sense. How could it reliably know the application-layer >> protocol? >> >> That is intentionally left unspecified. Otherwise it's a rat hole. >> >>> Since this is already a "RECOMMENDED" not a MUST, I think this phrase >> should be deleted. >> >> Well, that's the point of using the "RECOMMENDED ... UNLESS" idiom: to >> provide guidance as to when it is acceptable to deviate from the >> recommendation. > > I agree it's a rat hole to even mention, but since you're mentioning it anyway > you might be more explicit that it's not easy to know. Ok. > Also UNLESS isn't a term defined in 2119 and shouldn't be capitalized. > I'm not a fan of the "SHOULD ... unless" wording personally. Personally > I think it's cleaner to either have "MUST ... if/unless" for things that are > conditionally mandatory, or for conditional recommendations then two > separate sentences like "SHOULD blah. If blah, an implementation MAY > instead do blah." Thanks, I'll try to come up with clearer text. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From adurand@juniper.net Mon Nov 14 03:18:13 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B5D11E80BB for ; Mon, 14 Nov 2011 03:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXqBeUzWUcV4 for ; Mon, 14 Nov 2011 03:18:12 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5C85C11E809F for ; Mon, 14 Nov 2011 03:18:12 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTsD48/bjZGSbr/+3axYz/IZ26f3amYZE@postini.com; Mon, 14 Nov 2011 03:18:12 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 14 Nov 2011 03:14:47 -0800 From: Alain Durand To: "behave@ietf.org" Date: Mon, 14 Nov 2011 03:14:49 -0800 Thread-Topic: SD-NAT Thread-Index: Acyivp4t8BWfN4soSQGio0gHwZTdhA== Message-ID: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> 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: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 11:18:13 -0000 Dear Behave wg: SD-NAT ( http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 ) was pre= sented today in Softwire and will be presented again in Behave on Thursday. The overall feedback in Softwire was that SD-NAT is a stretch for this wg a= nd maybe Behave could be a better place as this is really CGN optimization.= So, I'd like to restart the discussion here on this mailling list in prepa= ration to the Behave meeting. ** So, what is SD-NAT and what problem does it solve? To deal with IPv4 exhaust, the commonly deployed approach today is IPv4 add= ress sharing, usually wih a CGN in NAT44 (or NAT444) if the access network = is IPv4 or with an AFTR in DS-Lite if the access network is IPv6. The messa= ge that came loud and clear to the IETF community was that service provider= s didn't like much having state and heavy logging in the middle of the netw= ork. Techniques like deterministic NAT have addressed the logging issue, bu= t the state remains an issue. In a nutshell, SD-NAT is a way to make those CGNs stateless by introducing = a simple configuration change on the CPEs. ** What does a stateless CGN bring to the table? Having a stateless CGN means higher performance, lower delay, lower cost an= d a very simple high availability solution. ** Related work A first answer was the so called 'stateless' approach in Softwire with IPv4= address & port mapping. SD-NAT is another (much simpler) approach to make = the CGN stateless, without introducing this notion of address and port mapp= ing. It makes no assumption on what kind of network, IPv4 or IPv6 there is = on the access network. In the SD-NAT architecture, the CPE remains essentia= lly unchanged (modulo a new configuration parameter). Just like in NAT44, N= AT444 or DS-Lite, the CPE does not need the explicit knowledge of which glo= bal IPv4 addres and port range it will be mapped to. ** How does SD-NAT work? The details are in the draft. At a hight level, the architecture relies on = the CPE to translate the src IP address to the one configured on it's WAN i= nterface (as usual), but not use the full [0-65535] port range, instead use= a limited range [1024-MaxPort]. That port range is the same for all CPEs. Because this range is fixed and known by the CGN, the CGN can programmatica= lly map it to a global IPv4 address and port range by shifting it's base IP= v4/port by a customer ID multiplied by the number of ports assigned per cus= tomers. All this is just shift/add/multiply on the CGN, there is no per session sta= te to maintain. - Alain.= From cb.list6@gmail.com Mon Nov 14 07:04:36 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6965C1F0C65 for ; Mon, 14 Nov 2011 07:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.039 X-Spam-Level: X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN-Umb+p-YUy for ; Mon, 14 Nov 2011 07:04:35 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B89E1F0C5F for ; Mon, 14 Nov 2011 07:04:35 -0800 (PST) Received: by yenq4 with SMTP id q4so3454826yen.31 for ; Mon, 14 Nov 2011 07:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NS66eK+cq1M3O9ioqNQI/iVq8qwbilyfw2Ly0Zyn4ww=; b=mTDoxUImyUtREFBn2HAHcqzL1FsZCFGbBXQJaVWijMCnsODdg/2IO+wfufuJvSqSNd MSDQdbQtW+J4JxGtsVGhGb3dUcaQRzjxmjQ9CvFihzscvRtcZo7D9abfV/mW81ZjY+DZ c36shmodHSdR7RlLNFf1vWo6M1a1yQPxtLBUI= MIME-Version: 1.0 Received: by 10.68.28.4 with SMTP id x4mr50489978pbg.56.1321283074656; Mon, 14 Nov 2011 07:04:34 -0800 (PST) Received: by 10.142.230.8 with HTTP; Mon, 14 Nov 2011 07:04:34 -0800 (PST) Received: by 10.142.230.8 with HTTP; Mon, 14 Nov 2011 07:04:34 -0800 (PST) In-Reply-To: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> Date: Mon, 14 Nov 2011 07:04:34 -0800 Message-ID: From: Cameron Byrne To: Alain Durand Content-Type: multipart/alternative; boundary=bcaec520eaed500b4604b1b33037 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 15:04:36 -0000 --bcaec520eaed500b4604b1b33037 Content-Type: text/plain; charset=ISO-8859-1 On Nov 14, 2011 3:18 AM, "Alain Durand" wrote: > > Dear Behave wg: > > SD-NAT ( http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 ) was presented today in Softwire and will be presented again in Behave on Thursday. > > The overall feedback in Softwire was that SD-NAT is a stretch for this wg and maybe Behave could be a better place as this is really CGN optimization. So, I'd like to restart the discussion here on this mailling list in preparation to the Behave meeting. > > ** So, what is SD-NAT and what problem does it solve? > > To deal with IPv4 exhaust, the commonly deployed approach today is IPv4 address sharing, usually wih a CGN in NAT44 (or NAT444) if the access network is IPv4 or with an AFTR in DS-Lite if the access network is IPv6. The message that came loud and clear to the IETF community was that service providers didn't like much having state and heavy logging in the middle of the network. Techniques like deterministic NAT have addressed the logging issue, but the state remains an issue. > > In a nutshell, SD-NAT is a way to make those CGNs stateless by introducing a simple configuration change on the CPEs. > > > ** What does a stateless CGN bring to the table? > > Having a stateless CGN means higher performance, lower delay, lower cost and a very simple high availability solution. > I have heard this several times but I have never seen these quantified I ask that the wg reject these assumptions until data is provided that specifically support each of these claims with quantifiable deltas of stateful vs stateless I am aware of the qualitative allure of stateless, but we should be data driven. Cb > ** Related work > > A first answer was the so called 'stateless' approach in Softwire with IPv4 address & port mapping. SD-NAT is another (much simpler) approach to make the CGN stateless, without introducing this notion of address and port mapping. It makes no assumption on what kind of network, IPv4 or IPv6 there is on the access network. In the SD-NAT architecture, the CPE remains essentially unchanged (modulo a new configuration parameter). Just like in NAT44, NAT444 or DS-Lite, the CPE does not need the explicit knowledge of which global IPv4 addres and port range it will be mapped to. > > > ** How does SD-NAT work? > > The details are in the draft. At a hight level, the architecture relies on the CPE to translate the src IP address to the one configured on it's WAN interface (as usual), but not use the full [0-65535] port range, instead use a limited range [1024-MaxPort]. That port range is the same for all CPEs. > Because this range is fixed and known by the CGN, the CGN can programmatically map it to a global IPv4 address and port range by shifting it's base IPv4/port by a customer ID multiplied by the number of ports assigned per customers. > > All this is just shift/add/multiply on the CGN, there is no per session state to maintain. > > - Alain. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --bcaec520eaed500b4604b1b33037 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 14, 2011 3:18 AM, "Alain Durand" <adurand@juniper.net> wrote:
>
> Dear Behave wg:
>
> SD-NAT ( http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 ) was = presented today in Softwire and will be presented again in Behave on Thursd= ay.
>
> The overall feedback in Softwire was that SD-NAT is a stretch for this= wg and maybe Behave could be a better place as this is really CGN optimiza= tion. So, I'd like to restart the discussion here on this mailling list= in preparation to the Behave meeting.
>
> ** So, what is SD-NAT and what problem does it solve?
>
> To deal with IPv4 exhaust, the commonly deployed approach today is IPv= 4 address sharing, usually wih a CGN in NAT44 (or NAT444) if the access net= work is IPv4 or with an AFTR in DS-Lite if the access network is IPv6. The = message that came loud and clear to the IETF community was that service pro= viders didn't like much having state and heavy logging in the middle of= the network. Techniques like deterministic NAT have addressed the logging = issue, but the state remains an issue.
>
> In a nutshell, SD-NAT is a way to make those CGNs stateless by introdu= cing a simple configuration change on the CPEs.
>
>
> ** What does a stateless CGN bring to the table?
>
> Having a stateless CGN means higher performance, lower delay, lower co= st and a very simple high availability solution.
>

I have heard this several times but I have never seen these quantified

I ask that the wg reject these assumptions until data is provided that s= pecifically support each of these claims with quantifiable deltas of statef= ul vs stateless

I am aware of the qualitative allure of stateless, but we should be data= driven.

Cb

> ** Related work
>
> A first answer was the so called 'stateless' approach in Softw= ire with IPv4 address & port mapping. SD-NAT is another (much simpler) = approach to make the CGN stateless, without introducing this notion of addr= ess and port mapping. It makes no assumption on what kind of network, IPv4 = or IPv6 there is on the access network. In the SD-NAT architecture, the CPE= remains essentially unchanged (modulo a new configuration parameter). Just= like in NAT44, NAT444 or DS-Lite, the CPE does not need the explicit knowl= edge of which global IPv4 addres and port range it will be mapped to.
>
>
> ** How does SD-NAT work?
>
> The details are in the draft. At a hight level, the architecture relie= s on the CPE to translate the src IP address to the one configured on it= 9;s WAN interface (as usual), but not use the full [0-65535] port range, in= stead use a limited range [1024-MaxPort]. That port range is the same for a= ll CPEs.
> Because this range is fixed and known by the CGN, the CGN can programm= atically map it to a global IPv4 address and port range by shifting it'= s base IPv4/port by a customer ID multiplied by the number of ports assigne= d per customers.
>
> All this is just shift/add/multiply on the CGN, there is no per sessio= n state to maintain.
>
> =A0 - Alain.
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave

--bcaec520eaed500b4604b1b33037-- From simon.perreault@viagenie.ca Mon Nov 14 12:41:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4A91F0C4A for ; Mon, 14 Nov 2011 12:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiwLNXVWX6Gn for ; Mon, 14 Nov 2011 12:41:11 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3E81F0C45 for ; Mon, 14 Nov 2011 12:41:11 -0800 (PST) Received: from [10.255.254.177] (bas1-malton22-1167905288.dsl.bell.ca [69.156.210.8]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D6B1B21F07 for ; Mon, 14 Nov 2011 15:40:39 -0500 (EST) Message-ID: <4EC17CC4.1010204@viagenie.ca> Date: Tue, 15 Nov 2011 05:40:36 +0900 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: behave@ietf.org References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 20:41:12 -0000 On 2011-11-15 00:04, Cameron Byrne wrote: > > Having a stateless CGN means higher performance, lower delay, lower > cost and a very simple high availability solution. > > > > I have heard this several times but I have never seen these quantified > > I ask that the wg reject these assumptions until data is provided that > specifically support each of these claims with quantifiable deltas of > stateful vs stateless > > I am aware of the qualitative allure of stateless, but we should be data > driven. Well, simplicity and high availability are qualitative and any classical networking textbook will demonstrate that stateless is better on these two aspects. I agree with you about the other claims (performance, delay, cost). Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From brian.e.carpenter@gmail.com Mon Nov 14 15:35:41 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F551F0C7D for ; Mon, 14 Nov 2011 15:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQlrYhwF3st4 for ; Mon, 14 Nov 2011 15:35:41 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39F9C1F0C64 for ; Mon, 14 Nov 2011 15:35:41 -0800 (PST) Received: by vws5 with SMTP id 5so6723474vws.31 for ; Mon, 14 Nov 2011 15:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=3iAlLBnLLhS2D9tzNVM58DaMUprEzYU3GDnUK8LH+XE=; b=dRj+CGgv4StS4SC4xIY6x8QQLvKw9M2FHhJwhfaluPCpbdv6JyWsEX8sNkHRM1fV6P +YBYYnWjihWmuyyzeRuxiXgm9fEBpmCR0s3EZeXIhGEg3REbjnO8Wy/qW11CdzAF5Vuu SzMTFDDdYjvU6U3796Pna214jKDSiNQgKeXso= Received: by 10.229.50.71 with SMTP id y7mr3552249qcf.167.1321313740578; Mon, 14 Nov 2011 15:35:40 -0800 (PST) Received: from [192.168.0.217] (61-31-89-133.static.tfn.net.tw. [61.31.89.133]) by mx.google.com with ESMTPS id cd3sm22723621qab.5.2011.11.14.15.35.38 (version=SSLv3 cipher=OTHER); Mon, 14 Nov 2011 15:35:39 -0800 (PST) Message-ID: <4EC1A5C5.5060107@gmail.com> Date: Tue, 15 Nov 2011 12:35:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alain Durand References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> In-Reply-To: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 23:35:41 -0000 I agree that this draft should be discussed somewhere that's interested in helping users and SPs to avoid IPv6 as long as possible. I'm not sure BEHAVE is such a place. > the architecture relies on the CPE to translate the src IP address to the one configured on it's WAN interface (as usual), but not use the full [0-65535] port range, instead use a limited range [1024-MaxPort]. That port range is the same for all CPEs. What % of existing CPEs can be remotely configured by the ISP to restrict the port range in this way? What % of existing CPEs cannot be configured remotely, but can be configured by the user to restrict the port range in this way? Regards Brian From adurand@juniper.net Mon Nov 14 17:17:14 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768D91F0CBF for ; Mon, 14 Nov 2011 17:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+HbeawGKo+t for ; Mon, 14 Nov 2011 17:17:14 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id CEC2B1F0C3F for ; Mon, 14 Nov 2011 17:17:13 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTsG9kVYc1JalWPM7gRAfIS2A5nKFKV8V@postini.com; Mon, 14 Nov 2011 17:17:13 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 14 Nov 2011 17:14:34 -0800 From: Alain Durand To: Simon Perreault Date: Mon, 14 Nov 2011 17:14:33 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcyjM+99dM/JBbaYRXC3XDnVATZRgg== Message-ID: <04EACFB6-BFB6-4BE8-B9A1-9606B6CF9AC5@juniper.net> References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC17CC4.1010204@viagenie.ca> In-Reply-To: <4EC17CC4.1010204@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] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:17:14 -0000 On Nov 15, 2011, at 4:41 AM, "Simon Perreault" wrote: > On 2011-11-15 00:04, Cameron Byrne wrote: >>> Having a stateless CGN means higher performance, lower delay, lower >> cost and a very simple high availability solution. >>>=20 >>=20 >> I have heard this several times but I have never seen these quantified >>=20 >> I ask that the wg reject these assumptions until data is provided that >> specifically support each of these claims with quantifiable deltas of >> stateful vs stateless >>=20 >> I am aware of the qualitative allure of stateless, but we should be data >> driven. >=20 > Well, simplicity and high availability are qualitative and any classical= =20 > networking textbook will demonstrate that stateless is better on these=20 > two aspects. >=20 > I agree with you about the other claims (performance, delay, cost). >=20 > Simon On the boxes I'm familiar with, NAT/CGN is done on service cards. The simpl= e reason is that it requires lots of memory to keep the state. A stateless = solution would enable to move the implementation to the line card and essen= tially do NAT at full lime rate. Huge difference. About high availability, doing fail-over of the full state table is possibl= e, but very expensive. In a stateless solution like SD-NAT, you simply rely= on anycast to achieve HA. See the draft for details. Alain. From adurand@juniper.net Mon Nov 14 17:25:40 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7B31F0D28 for ; Mon, 14 Nov 2011 17:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2wZn8-az26m for ; Mon, 14 Nov 2011 17:25:37 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 564F51F0CF6 for ; Mon, 14 Nov 2011 17:25:36 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTsG/j2DZyL1uqAo4RvHBPhmEZMJn8WAf@postini.com; Mon, 14 Nov 2011 17:25:36 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 14 Nov 2011 17:23:43 -0800 From: Alain Durand To: Brian E Carpenter Date: Mon, 14 Nov 2011 17:23:42 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcyjNTYjnEjQgt+FQdu/GjF77xr0JQ== Message-ID: <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> In-Reply-To: <4EC1A5C5.5060107@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:25:40 -0000 DQpPbiBOb3YgMTUsIDIwMTEsIGF0IDc6MzUgQU0sICJCcmlhbiBFIENhcnBlbnRlciIgPGJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQoNCj4gSSBhZ3JlZSB0aGF0IHRoaXMgZHJh ZnQgc2hvdWxkIGJlIGRpc2N1c3NlZCBzb21ld2hlcmUgdGhhdCdzIGludGVyZXN0ZWQgaW4gaGVs cGluZw0KPiB1c2VycyBhbmQgU1BzIHRvIGF2b2lkIElQdjYgYXMgbG9uZyBhcyBwb3NzaWJsZS4g SSdtIG5vdCBzdXJlIEJFSEFWRSBpcyBzdWNoDQo+IGEgcGxhY2UuDQo+IA0KPj4gdGhlIGFyY2hp dGVjdHVyZSByZWxpZXMgb24gdGhlIENQRSB0byB0cmFuc2xhdGUgdGhlIHNyYyBJUCBhZGRyZXNz IHRvIHRoZSBvbmUgY29uZmlndXJlZCBvbiBpdCdzIFdBTiBpbnRlcmZhY2UgKGFzIHVzdWFsKSwg YnV0IG5vdCB1c2UgdGhlIGZ1bGwgWzAtNjU1MzVdIHBvcnQgcmFuZ2UsIGluc3RlYWQgdXNlIGEg bGltaXRlZCByYW5nZSBbMTAyNC1NYXhQb3J0XS4gVGhhdCBwb3J0IHJhbmdlIGlzIHRoZSBzYW1l IGZvciBhbGwgQ1BFcy4NCj4gDQo+IFdoYXQgJSBvZiBleGlzdGluZyBDUEVzIGNhbiBiZSByZW1v dGVseSBjb25maWd1cmVkIGJ5IHRoZSBJU1AgdG8gcmVzdHJpY3QgdGhlIHBvcnQgcmFuZ2UgaW4g dGhpcyB3YXk/DQo+IA0KPiBXaGF0ICUgb2YgZXhpc3RpbmcgQ1BFcyBjYW5ub3QgYmUgY29uZmln dXJlZCByZW1vdGVseSwgYnV0IGNhbiBiZSBjb25maWd1cmVkIGJ5IHRoZSB1c2VyIHRvIHJlc3Ry aWN0IHRoZSBwb3J0IHJhbmdlIGluIHRoaXMgd2F5Pw0KDQpUaGUgZnVuY3Rpb25hbGl0eSBpcyBw YXJ0IG9mIHRoZSBiYXNpYyBJUFRBQkxFUyBtb2R1bGUgb24gTGludXguIFRoZXJlIGFyZSBhcHBh cmVudGx5IGEgY291cGxlIGRpZmZlcmVudCBmYXZvcnMsIGJ1dCB0aGV5IGFsbCBoYXZlIHRoZSBm dW5jdGlvbmFsaXR5Lg0KDQpFeGFtcGxlIG9uIExpbnV4IGJhc2VkIENQRSAoT3Blbi1XUlQsIOKA pikNCg0KL2xpYi9maXJld2FsbC91Y2lfZmlyZXdhbGwuc2gNCg0KT0xEOg0KJElQVEFCTEVTIC1J IHpvbmVfJHt6b25lfV9uYXQgMSAtdCBuYXQgLW8gIiRpZm5hbWUiIC1qIE1BU1FVRVJBREUNCg0K TkVXOg0KJElQVEFCTEVTIC1JIHpvbmVfJHt6b25lfV9uYXQgMSAtdCBuYXQgLW8gIiRpZm5hbWUi IC1qIE1BU1FVRVJBREUgLXAgdGNwIC0tdG8tcG9ydHMgMTAyNC0yMDIzDQoNCkFsYWluLg0K From marc.blanchet@viagenie.ca Mon Nov 14 17:28:36 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993B41F0D33 for ; Mon, 14 Nov 2011 17:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06V62GFO3QQj for ; Mon, 14 Nov 2011 17:28:36 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 12D451F0D3C for ; Mon, 14 Nov 2011 17:28:36 -0800 (PST) Received: from [IPv6:2001:df8::80:61b5:fb08:2d88:da18] (unknown [IPv6:2001:df8:0:80:61b5:fb08:2d88:da18]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A213B20CC2; Mon, 14 Nov 2011 20:28:04 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Marc Blanchet In-Reply-To: <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> Date: Tue, 15 Nov 2011 09:28:01 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7C55F961-6956-4A40-A916-44F20B6AA249@viagenie.ca> References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1251.1) Cc: "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:28:36 -0000 does the number of ports allocated on each CPE (i.e. 1024-2023 in the = below example) need to be synchronized (i.e. same number of ports per = CPE) with the configuration of the CGN? Marc. Le 2011-11-15 =E0 09:23, Alain Durand a =E9crit : >=20 > On Nov 15, 2011, at 7:35 AM, "Brian E Carpenter" = wrote: >=20 >> I agree that this draft should be discussed somewhere that's = interested in helping >> users and SPs to avoid IPv6 as long as possible. I'm not sure BEHAVE = is such >> a place. >>=20 >>> the architecture relies on the CPE to translate the src IP address = to the one configured on it's WAN interface (as usual), but not use the = full [0-65535] port range, instead use a limited range [1024-MaxPort]. = That port range is the same for all CPEs. >>=20 >> What % of existing CPEs can be remotely configured by the ISP to = restrict the port range in this way? >>=20 >> What % of existing CPEs cannot be configured remotely, but can be = configured by the user to restrict the port range in this way? >=20 > The functionality is part of the basic IPTABLES module on Linux. There = are apparently a couple different favors, but they all have the = functionality. >=20 > Example on Linux based CPE (Open-WRT, =85) >=20 > /lib/firewall/uci_firewall.sh >=20 > OLD: > $IPTABLES -I zone_${zone}_nat 1 -t nat -o "$ifname" -j MASQUERADE >=20 > NEW: > $IPTABLES -I zone_${zone}_nat 1 -t nat -o "$ifname" -j MASQUERADE -p = tcp --to-ports 1024-2023 >=20 > Alain. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From cb.list6@gmail.com Mon Nov 14 17:37:46 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62ADE21F8EB1 for ; Mon, 14 Nov 2011 17:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.059 X-Spam-Level: X-Spam-Status: No, score=-3.059 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLdO6p32Q156 for ; Mon, 14 Nov 2011 17:37:45 -0800 (PST) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9C75921F8EAD for ; Mon, 14 Nov 2011 17:37:45 -0800 (PST) Received: by pzk5 with SMTP id 5so11363280pzk.9 for ; Mon, 14 Nov 2011 17:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BFNISziwWXU50Ib8PCRwjutVn/EETVvkm7g9EOh6EUo=; b=jiWtbrWHZDT8qB4+fsFgbPFm+2twj59HQKMpCZQ5YrSGCPyC5s64XzmGvTusheoE3k 6rX1oauWoP2rLfRA1SfQpnr2TfftLQ3NH3uLsdnrDc4Fb9cruPzRgZT3E13ARuHMTfRZ ZtXIX93UhZUvLMrX8xibuCFZibjgnrggSZ2bw= MIME-Version: 1.0 Received: by 10.68.5.162 with SMTP id t2mr55597410pbt.73.1321321064887; Mon, 14 Nov 2011 17:37:44 -0800 (PST) Received: by 10.142.230.8 with HTTP; Mon, 14 Nov 2011 17:37:44 -0800 (PST) Received: by 10.142.230.8 with HTTP; Mon, 14 Nov 2011 17:37:44 -0800 (PST) In-Reply-To: <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> Date: Mon, 14 Nov 2011 17:37:44 -0800 Message-ID: From: Cameron Byrne To: Alain Durand Content-Type: multipart/alternative; boundary=bcaec52159a5b4f5e004b1bc0853 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:37:46 -0000 --bcaec52159a5b4f5e004b1bc0853 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Nov 14, 2011 5:25 PM, "Alain Durand" wrote: > > > On Nov 15, 2011, at 7:35 AM, "Brian E Carpenter" < brian.e.carpenter@gmail.com> wrote: > > > I agree that this draft should be discussed somewhere that's interested in helping > > users and SPs to avoid IPv6 as long as possible. I'm not sure BEHAVE is such > > a place. > > > >> the architecture relies on the CPE to translate the src IP address to the one configured on it's WAN interface (as usual), but not use the full [0-65535] port range, instead use a limited range [1024-MaxPort]. That port range is the same for all CPEs. > > > > What % of existing CPEs can be remotely configured by the ISP to restrict the port range in this way? > > > > What % of existing CPEs cannot be configured remotely, but can be configured by the user to restrict the port range in this way? > > The functionality is part of the basic IPTABLES module on Linux. There are apparently a couple different favors, but they all have the functionality. > > Example on Linux based CPE (Open-WRT, =85) > > /lib/firewall/uci_firewall.sh > > OLD: > $IPTABLES -I zone_${zone}_nat 1 -t nat -o "$ifname" -j MASQUERADE > > NEW: > $IPTABLES -I zone_${zone}_nat 1 -t nat -o "$ifname" -j MASQUERADE -p tcp --to-ports 1024-2023 > Using this logic, deploying native ipv6 is trivial on home routers too, right? My understanding of the market is that home routers will almost uniformly need a forklift to support ipv6 .... And this sd nat as well. It's more a market dynamic issue than a technical one. I will put in a guess that for North America both percentages are less than 1, therefore this solution requires a long term commitment from the sp and greenfield cpe deployment. Cb > Alain > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --bcaec52159a5b4f5e004b1bc0853 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Nov 14, 2011 5:25 PM, "Alain Durand" <adurand@juniper.net> wrote:
>
>
> On Nov 15, 2011, at 7:35 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com>= wrote:
>
> > I agree that this draft should be discussed somewhere that's = interested in helping
> > users and SPs to avoid IPv6 as long as possible. I'm not sure= BEHAVE is such
> > a place.
> >
> >> the architecture relies on the CPE to translate the src IP ad= dress to the one configured on it's WAN interface (as usual), but not u= se the full [0-65535] port range, instead use a limited range [1024-MaxPort= ]. That port range is the same for all CPEs.
> >
> > What % of existing CPEs can be remotely configured by the ISP to = restrict the port range in this way?
> >
> > What % of existing CPEs cannot be configured remotely, but can be= configured by the user to restrict the port range in this way?
>
> The functionality is part of the basic IPTABLES module on Linux. There= are apparently a couple different favors, but they all have the functional= ity.
>
> Example on Linux based CPE (Open-WRT, =85)
>
> /lib/firewall/uci_firewall.sh
>
> OLD:
> $IPTABLES -I zone_${zone}_nat 1 -t nat -o "$ifname" -j MASQU= ERADE
>
> NEW:
> $IPTABLES -I zone_${zone}_nat 1 -t nat -o "$ifname" -j MASQU= ERADE -p tcp --to-ports 1024-2023
>

Using this logic, deploying native ipv6 is trivial on home routers too, = right?

My understanding of the market is that home routers will almost uniforml= y need a forklift to support=A0 ipv6 .... And this sd nat as well.=A0 It= 9;s more a market dynamic issue than a technical one.

I will put in a guess that for North America both percentages are less = than 1, therefore this solution requires a long term commitment from the sp= and greenfield cpe deployment.

Cb

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

--bcaec52159a5b4f5e004b1bc0853-- From adurand@juniper.net Mon Nov 14 17:46:08 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00ED11E817F for ; Mon, 14 Nov 2011 17:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id impRGGKwRuSL for ; Mon, 14 Nov 2011 17:46:08 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9FA11E8152 for ; Mon, 14 Nov 2011 17:46:08 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTsHEXbloO4SrZ4P5k3aTkAjRJy8wWtyk@postini.com; Mon, 14 Nov 2011 17:46:08 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 14 Nov 2011 17:45:35 -0800 From: Alain Durand To: Marc Blanchet Date: Mon, 14 Nov 2011 17:45:33 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcyjOERmSEr7nbV5SGywMM7B7Lfu2g== Message-ID: <5DCA01A5-43DF-4B7F-9D4D-20149AD46862@juniper.net> References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> <7C55F961-6956-4A40-A916-44F20B6AA249@viagenie.ca> In-Reply-To: <7C55F961-6956-4A40-A916-44F20B6AA249@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] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:46:08 -0000 On Nov 14, 2011, at 8:28 PM, "Marc Blanchet" wr= ote: > does the number of ports allocated on each CPE (i.e. 1024-2023 in the bel= ow example) need to be synchronized (i.e. same number of ports per CPE) wit= h the configuration of the CGN? This is a matter of how much provisioning the service provider is willing t= o do. The simplest model is same number of ports for everybody. The next level is to group subscriber in different categories, make sure th= eir WAN IP address in in a common IP prefix. Then you can easily have a dif= ferent number of ports per subscriber in each category. The extreme end of this spectrum is a static per-user mapping table loaded = on the CGNs. Note: this remains stateless on a per session basis. Alain.= From adurand@juniper.net Mon Nov 14 17:57:01 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F7611E816C for ; Mon, 14 Nov 2011 17:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DebebLLoKAOw for ; Mon, 14 Nov 2011 17:57:00 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id A576211E812C for ; Mon, 14 Nov 2011 17:57:00 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTsHG6sPzoBOAsk3EwD9zdxe6h5WCmBNY@postini.com; Mon, 14 Nov 2011 17:57:00 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 14 Nov 2011 17:56:05 -0800 From: Alain Durand To: Cameron Byrne Date: Mon, 14 Nov 2011 17:56:03 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcyjObvMZc0TpENfT1uZ5LtUdbyZsw== Message-ID: <7A1E3CAC-BB1E-42CC-BF26-388938ECD93E@juniper.net> References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:57:01 -0000 T24gTm92IDE0LCAyMDExLCBhdCA4OjM3IFBNLCAiQ2FtZXJvbiBCeXJuZSIgPGNiLmxpc3Q2QGdt YWlsLmNvbTxtYWlsdG86Y2IubGlzdDZAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KVXNpbmcgdGhp cyBsb2dpYywgZGVwbG95aW5nIG5hdGl2ZSBpcHY2IGlzIHRyaXZpYWwgb24gaG9tZSByb3V0ZXJz IHRvbywgcmlnaHQ/DQoNCk5vdCBuZWNlc3NhcmlseS4NCkEgbnVtYmVyIG9mIElTUCB0aGF0IHBy b3ZpZGUgQ1BFIHRvIHRoZWlyIGN1c3RvbWVycyBoYXZlIHRvbGQgbWUgdGhhdCBnZXR0aW5nIHNp bXBsZSBJUHY0IHBhdGNoIGZvciB0aGVpciB2ZW5kb3Igd2FzIHJlbGF0aXZlbHkgZWFzeSwgZ2V0 dGluZyBJUHY2IHdhcyBtdWNoIGhhcmRlci4NCg0KDQpNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBt YXJrZXQgaXMgdGhhdCBob21lIHJvdXRlcnMgd2lsbCBhbG1vc3QgdW5pZm9ybWx5IG5lZWQgYSBm b3JrbGlmdCB0byBzdXBwb3J0ICBpcHY2IC4uLi4gQW5kIHRoaXMgc2QgbmF0IGFzIHdlbGwuICBJ dCdzIG1vcmUgYSBtYXJrZXQgZHluYW1pYyBpc3N1ZSB0aGFuIGEgdGVjaG5pY2FsIG9uZS4NCg0K SSBhZ3JlZSB3aXRoIHRoZSAxc3QgcGFydCBvZiB5b3VyIGFzc2VydGlvbiwgYnV0IG5vdCBuZWNl c3NhcmlseSB3aXRoIHRoZSBzZWNvbmQgb25lLiBZZXMsIFNELU5BVCBpbnRyb2R1Y2UgYSBjaGFu Z2Ugb24gdGhlIENQRXMsIHllcywgdGhlIGxlZ2FjeSByZXRhaWwgQ1BFcyBtYXkgYmUgb3V0IG9m IHJlYWNoLCBidXQgdGhlIHRoaXMgc2VlbXMgdG8gYmUgZG9hYmxlIG9uIG1hbmFnZWQgQ1BFcyBv ciBhbnkgZGV2aWNlIHdoZXJlIGNvZGUgcGF0Y2ggY2FuIGJlIHVwbG9hZGVkIChlZyBhIHNtYXJ0 IHBob25lKQ0KDQpBbGFpbi4NCg== From marc.blanchet@viagenie.ca Mon Nov 14 17:59:37 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BD911E82C0 for ; Mon, 14 Nov 2011 17:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyAyt1jqXzsw for ; Mon, 14 Nov 2011 17:59:37 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 14E4D11E816C for ; Mon, 14 Nov 2011 17:59:37 -0800 (PST) Received: from [IPv6:2001:df8::80:61b5:fb08:2d88:da18] (unknown [IPv6:2001:df8:0:80:61b5:fb08:2d88:da18]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D0D5220CC2; Mon, 14 Nov 2011 20:59:05 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <5DCA01A5-43DF-4B7F-9D4D-20149AD46862@juniper.net> Date: Tue, 15 Nov 2011 09:59:03 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <48A63CA0-6A3D-4391-B061-DF4974293230@viagenie.ca> References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> <7C55F961-6956-4A40-A916-44F20B6AA249@viagenie.ca> <5DCA01A5-43DF-4B7F-9D4D-20149AD46862@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1251.1) Cc: behave@ietf.org Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:59:38 -0000 say CGN is configured for 1000 ports per user. Ehat happens if one CPE1 = is configured 1024-2023 and CPE2 is configured 1024-3050 and they are in = the same CGN domain? (for example, CPE1 vendor is X, CPE2 vendor is Y = and they have different default setup). What happens to the CGN about = the fact that CPE2 can not use 2024-3050? let it use them and overlap = with the user of CPE3? error message? silent drop? Marc. Le 2011-11-15 =E0 09:45, Alain Durand a =E9crit : > On Nov 14, 2011, at 8:28 PM, "Marc Blanchet" = wrote: >=20 >> does the number of ports allocated on each CPE (i.e. 1024-2023 in the = below example) need to be synchronized (i.e. same number of ports per = CPE) with the configuration of the CGN? >=20 > This is a matter of how much provisioning the service provider is = willing to do. >=20 > The simplest model is same number of ports for everybody. > The next level is to group subscriber in different categories, make = sure their WAN IP address in in a common IP prefix. Then you can easily = have a different number of ports per subscriber in each category. > The extreme end of this spectrum is a static per-user mapping table = loaded on the CGNs. Note: this remains stateless on a per session basis. >=20 > Alain. From sarikaya2012@gmail.com Mon Nov 14 18:06:05 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5197D1F0CDF for ; Mon, 14 Nov 2011 18:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRK-spG0MOli for ; Mon, 14 Nov 2011 18:06:04 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99EE71F0CBF for ; Mon, 14 Nov 2011 18:06:04 -0800 (PST) Received: by yenq4 with SMTP id q4so4178040yen.31 for ; Mon, 14 Nov 2011 18:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1Oqu7IxKkQdDlVfsptmC00JpV8nh9z2VgZccTQgILkI=; b=WQKZEuWlW+eb48EKbQgp0t94ZS32ZrEvC7CY8yj9Haotez4H80mDjSeBXpLINf61gN wGUzgR1Krp8X5McX8mJw+f4q1kSxg2jDXtx1Eo6Y+BoWgC37+xyd+GqHfYakB+gyQuak I8C4fF8YJY/IdCeWVcgm7cHoppEHwiq6NJKHk= MIME-Version: 1.0 Received: by 10.146.236.17 with SMTP id j17mr264277yah.10.1321322764177; Mon, 14 Nov 2011 18:06:04 -0800 (PST) Received: by 10.236.191.228 with HTTP; Mon, 14 Nov 2011 18:06:04 -0800 (PST) In-Reply-To: <48A63CA0-6A3D-4391-B061-DF4974293230@viagenie.ca> References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> <7C55F961-6956-4A40-A916-44F20B6AA249@viagenie.ca> <5DCA01A5-43DF-4B7F-9D4D-20149AD46862@juniper.net> <48A63CA0-6A3D-4391-B061-DF4974293230@viagenie.ca> Date: Mon, 14 Nov 2011 20:06:04 -0600 Message-ID: From: Behcet Sarikaya To: Marc Blanchet Content-Type: multipart/alternative; boundary=000e0cd567eefe123504b1bc6df0 Cc: behave@ietf.org, Alain Durand Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:06:05 -0000 --000e0cd567eefe123504b1bc6df0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marc, I think the assumption is that each CPE has a different WAN address. No shara. Regards, Behcet On Mon, Nov 14, 2011 at 7:59 PM, Marc Blanchet w= rote: > say CGN is configured for 1000 ports per user. Ehat happens if one CPE1 > is configured 1024-2023 and CPE2 is configured 1024-3050 and they are in > the same CGN domain? (for example, CPE1 vendor is X, CPE2 vendor is Y an= d > they have different default setup). What happens to the CGN about the fac= t > that CPE2 can not use 2024-3050? let it use them and overlap with the use= r > of CPE3? error message? silent drop? > > Marc. > > Le 2011-11-15 =E0 09:45, Alain Durand a =E9crit : > > > On Nov 14, 2011, at 8:28 PM, "Marc Blanchet" > wrote: > > > >> does the number of ports allocated on each CPE (i.e. 1024-2023 in the > below example) need to be synchronized (i.e. same number of ports per CPE= ) > with the configuration of the CGN? > > > > This is a matter of how much provisioning the service provider is > willing to do. > > > > The simplest model is same number of ports for everybody. > > The next level is to group subscriber in different categories, make sur= e > their WAN IP address in in a common IP prefix. Then you can easily have a > different number of ports per subscriber in each category. > > The extreme end of this spectrum is a static per-user mapping table > loaded on the CGNs. Note: this remains stateless on a per session basis. > > > > Alain. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --000e0cd567eefe123504b1bc6df0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marc,

I think the assumption is that each CPE has a different WAN= address. No shara.

Regards,

Behcet

On Mon, Nov 14, 2011 at 7:59 PM, Marc Blanchet &= lt;marc.blanchet@viagenie.ca> wrote:
say CGN is configured for 1000 ports per us= er. =A0Ehat happens if one CPE1 is configured 1024-2023 and CPE2 is configu= red 1024-3050 and they are in the same CGN domain? =A0(for example, CPE1 ve= ndor is X, CPE2 vendor is Y and they have different default setup). What ha= ppens to the CGN about the fact that CPE2 can not use 2024-3050? let it use= them and overlap with the user of CPE3? error message? silent drop?

Marc.

Le 2011-11-15 =E0 09:45, Alain Durand a =E9crit :

> On Nov 14, 2011, at 8:28 PM, "Marc Blanchet" <marc.blanchet@viagenie.ca> wrote:<= br> >
>> does the number of ports allocated on each CPE (i.e. 1024-2023 in = the below example) need to be synchronized (i.e. same number of ports per C= PE) with the configuration of the CGN?
>
> This is a matter of how much provisioning the service provider is will= ing to do.
>
> The simplest model is same number of ports for everybody.
> The next level is to group subscriber in different categories, make su= re their WAN IP address in in a common IP prefix. Then you can easily have = a different number of ports per subscriber in each category.
> The extreme end of this spectrum is a static per-user mapping table lo= aded on the CGNs. Note: this remains stateless on a per session basis.
>
> Alain.

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

--000e0cd567eefe123504b1bc6df0-- From rajeshm@juniper.net Mon Nov 14 18:07:25 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00571F0D3C for ; Mon, 14 Nov 2011 18:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.522 X-Spam-Level: X-Spam-Status: No, score=-4.522 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjLn5ZsQWSVK for ; Mon, 14 Nov 2011 18:07:25 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 08A4C1F0D39 for ; Mon, 14 Nov 2011 18:07:24 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTsHJW0lUgW4xiuEX6/7q0miMPCfwpsKC@postini.com; Mon, 14 Nov 2011 18:07:25 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 14 Nov 2011 18:06:43 -0800 From: Rajesh Mohan To: Marc Blanchet , Alain Durand Date: Mon, 14 Nov 2011 18:06:42 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcyjOj2AMbxlXDz+TbuKsjncoPgokwAANvig Message-ID: References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> <7C55F961-6956-4A40-A916-44F20B6AA249@viagenie.ca> <5DCA01A5-43DF-4B7F-9D4D-20149AD46862@juniper.net> <48A63CA0-6A3D-4391-B061-DF4974293230@viagenie.ca> In-Reply-To: <48A63CA0-6A3D-4391-B061-DF4974293230@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:07:26 -0000 The draft proposes (Section 4.6) that an ICMP error message type 13 be sent= . -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Marc Blanchet Sent: Monday, November 14, 2011 5:59 PM To: Alain Durand Cc: behave@ietf.org Subject: Re: [BEHAVE] SD-NAT say CGN is configured for 1000 ports per user. Ehat happens if one CPE1 is= configured 1024-2023 and CPE2 is configured 1024-3050 and they are in the = same CGN domain? (for example, CPE1 vendor is X, CPE2 vendor is Y and they= have different default setup). What happens to the CGN about the fact that= CPE2 can not use 2024-3050? let it use them and overlap with the user of C= PE3? error message? silent drop? Marc. Le 2011-11-15 =E0 09:45, Alain Durand a =E9crit : > On Nov 14, 2011, at 8:28 PM, "Marc Blanchet" = wrote: >=20 >> does the number of ports allocated on each CPE (i.e. 1024-2023 in the be= low example) need to be synchronized (i.e. same number of ports per CPE) wi= th the configuration of the CGN? >=20 > This is a matter of how much provisioning the service provider is willing= to do. >=20 > The simplest model is same number of ports for everybody. > The next level is to group subscriber in different categories, make sure = their WAN IP address in in a common IP prefix. Then you can easily have a d= ifferent number of ports per subscriber in each category. > The extreme end of this spectrum is a static per-user mapping table loade= d on the CGNs. Note: this remains stateless on a per session basis. >=20 > Alain. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From marc.blanchet@viagenie.ca Mon Nov 14 18:08:20 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D411F0D36 for ; Mon, 14 Nov 2011 18:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqO1CEsf6Bgs for ; Mon, 14 Nov 2011 18:08:20 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 13AA81F0D3C for ; Mon, 14 Nov 2011 18:08:20 -0800 (PST) Received: from [IPv6:2001:df8::80:61b5:fb08:2d88:da18] (unknown [IPv6:2001:df8:0:80:61b5:fb08:2d88:da18]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 086F220CC2; Mon, 14 Nov 2011 21:07:48 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: Date: Tue, 15 Nov 2011 10:07:46 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> <7C55F961-6956-4A40-A916-44F20B6AA249@viagenie.ca> <5DCA01A5-43DF-4B7F-9D4D-20149AD46862@juniper.net> <48A63CA0-6A3D-4391-B061-DF4974293230@viagenie.ca> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1251.1) Cc: behave@ietf.org Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:08:20 -0000 Le 2011-11-15 =E0 10:06, Behcet Sarikaya a =E9crit : > Hi Marc, >=20 > I think the assumption is that each CPE has a different WAN address. indeed. I was assuming it. My question is the behavior of the CGN in the = case below. Like when a CGN is out of ports for an end-user? Marc. > No shara. >=20 > Regards, >=20 > Behcet >=20 > On Mon, Nov 14, 2011 at 7:59 PM, Marc Blanchet = wrote: > say CGN is configured for 1000 ports per user. Ehat happens if one = CPE1 is configured 1024-2023 and CPE2 is configured 1024-3050 and they = are in the same CGN domain? (for example, CPE1 vendor is X, CPE2 vendor = is Y and they have different default setup). What happens to the CGN = about the fact that CPE2 can not use 2024-3050? let it use them and = overlap with the user of CPE3? error message? silent drop? >=20 > Marc. >=20 > Le 2011-11-15 =E0 09:45, Alain Durand a =E9crit : >=20 > > On Nov 14, 2011, at 8:28 PM, "Marc Blanchet" = wrote: > > > >> does the number of ports allocated on each CPE (i.e. 1024-2023 in = the below example) need to be synchronized (i.e. same number of ports = per CPE) with the configuration of the CGN? > > > > This is a matter of how much provisioning the service provider is = willing to do. > > > > The simplest model is same number of ports for everybody. > > The next level is to group subscriber in different categories, make = sure their WAN IP address in in a common IP prefix. Then you can easily = have a different number of ports per subscriber in each category. > > The extreme end of this spectrum is a static per-user mapping table = loaded on the CGNs. Note: this remains stateless on a per session basis. > > > > Alain. >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 From adurand@juniper.net Mon Nov 14 18:18:01 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0254411E810C for ; Mon, 14 Nov 2011 18:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPhWocdeulAq for ; Mon, 14 Nov 2011 18:18:00 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 3183711E80A4 for ; Mon, 14 Nov 2011 18:18:00 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTsHL1vbuGoFc1Xar/TqSJ4X4ufysk8Wo@postini.com; Mon, 14 Nov 2011 18:18:00 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 14 Nov 2011 18:14:51 -0800 From: Alain Durand To: "sarikaya@ieee.org" Date: Mon, 14 Nov 2011 18:14:49 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcyjPFsC7mUOaep2SL6gHTUyCC394A== Message-ID: <3C54EACF-DF4D-4DE3-A194-49E5EA7F281A@juniper.net> References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> <7C55F961-6956-4A40-A916-44F20B6AA249@viagenie.ca> <5DCA01A5-43DF-4B7F-9D4D-20149AD46862@juniper.net> <48A63CA0-6A3D-4391-B061-DF4974293230@viagenie.ca> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Marc Blanchet , "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:18:01 -0000 Q29ycmVjdC4NCkVhY2ggQ1BFIGhhcyBhIHVuaXF1ZSBXQU4gYWRkcmVzcyAocHJpdmF0ZSB2NCBv ciB2NikuDQpBbGwgQ1BFcyAoaW4gYSBjYXRlZ29yeSkgdXNlIHRoZSBzYW1lIHBvcnQgcmFuZ2Ug WzEwMjQuLi5NYXhwb3J0XQ0KDQpBbGFpbi4NCg0KDQpPbiBOb3YgMTQsIDIwMTEsIGF0IDk6MDYg UE0sICJCZWhjZXQgU2FyaWtheWEiIDxzYXJpa2F5YTIwMTJAZ21haWwuY29tPG1haWx0bzpzYXJp a2F5YTIwMTJAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpIE1hcmMsDQoNCkkgdGhpbmsgdGhlIGFz c3VtcHRpb24gaXMgdGhhdCBlYWNoIENQRSBoYXMgYSBkaWZmZXJlbnQgV0FOIGFkZHJlc3MuIE5v IHNoYXJhLg0KDQpSZWdhcmRzLA0KDQpCZWhjZXQNCg0KT24gTW9uLCBOb3YgMTQsIDIwMTEgYXQg Nzo1OSBQTSwgTWFyYyBCbGFuY2hldCA8bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYTxtYWlsdG86 bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYT4+IHdyb3RlOg0Kc2F5IENHTiBpcyBjb25maWd1cmVk IGZvciAxMDAwIHBvcnRzIHBlciB1c2VyLiAgRWhhdCBoYXBwZW5zIGlmIG9uZSBDUEUxIGlzIGNv bmZpZ3VyZWQgMTAyNC0yMDIzIGFuZCBDUEUyIGlzIGNvbmZpZ3VyZWQgMTAyNC0zMDUwIGFuZCB0 aGV5IGFyZSBpbiB0aGUgc2FtZSBDR04gZG9tYWluPyAgKGZvciBleGFtcGxlLCBDUEUxIHZlbmRv ciBpcyBYLCBDUEUyIHZlbmRvciBpcyBZIGFuZCB0aGV5IGhhdmUgZGlmZmVyZW50IGRlZmF1bHQg c2V0dXApLiBXaGF0IGhhcHBlbnMgdG8gdGhlIENHTiBhYm91dCB0aGUgZmFjdCB0aGF0IENQRTIg Y2FuIG5vdCB1c2UgMjAyNC0zMDUwPyBsZXQgaXQgdXNlIHRoZW0gYW5kIG92ZXJsYXAgd2l0aCB0 aGUgdXNlciBvZiBDUEUzPyBlcnJvciBtZXNzYWdlPyBzaWxlbnQgZHJvcD8NCg0KTWFyYy4NCg0K TGUgMjAxMS0xMS0xNSDDoCAwOTo0NSwgQWxhaW4gRHVyYW5kIGEgw6ljcml0IDoNCg0KPiBPbiBO b3YgMTQsIDIwMTEsIGF0IDg6MjggUE0sICJNYXJjIEJsYW5jaGV0IiA8bWFyYy5ibGFuY2hldEB2 aWFnZW5pZS5jYTxtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYT4+IHdyb3RlOg0KPg0K Pj4gZG9lcyB0aGUgbnVtYmVyIG9mIHBvcnRzIGFsbG9jYXRlZCBvbiBlYWNoIENQRSAoaS5lLiAx MDI0LTIwMjMgaW4gdGhlIGJlbG93IGV4YW1wbGUpIG5lZWQgdG8gYmUgc3luY2hyb25pemVkIChp LmUuIHNhbWUgbnVtYmVyIG9mIHBvcnRzIHBlciBDUEUpIHdpdGggdGhlIGNvbmZpZ3VyYXRpb24g b2YgdGhlIENHTj8NCj4NCj4gVGhpcyBpcyBhIG1hdHRlciBvZiBob3cgbXVjaCBwcm92aXNpb25p bmcgdGhlIHNlcnZpY2UgcHJvdmlkZXIgaXMgd2lsbGluZyB0byBkby4NCj4NCj4gVGhlIHNpbXBs ZXN0IG1vZGVsIGlzIHNhbWUgbnVtYmVyIG9mIHBvcnRzIGZvciBldmVyeWJvZHkuDQo+IFRoZSBu ZXh0IGxldmVsIGlzIHRvIGdyb3VwIHN1YnNjcmliZXIgaW4gZGlmZmVyZW50IGNhdGVnb3JpZXMs IG1ha2Ugc3VyZSB0aGVpciBXQU4gSVAgYWRkcmVzcyBpbiBpbiBhIGNvbW1vbiBJUCBwcmVmaXgu IFRoZW4geW91IGNhbiBlYXNpbHkgaGF2ZSBhIGRpZmZlcmVudCBudW1iZXIgb2YgcG9ydHMgcGVy IHN1YnNjcmliZXIgaW4gZWFjaCBjYXRlZ29yeS4NCj4gVGhlIGV4dHJlbWUgZW5kIG9mIHRoaXMg c3BlY3RydW0gaXMgYSBzdGF0aWMgcGVyLXVzZXIgbWFwcGluZyB0YWJsZSBsb2FkZWQgb24gdGhl IENHTnMuIE5vdGU6IHRoaXMgcmVtYWlucyBzdGF0ZWxlc3Mgb24gYSBwZXIgc2Vzc2lvbiBiYXNp cy4NCj4NCj4gQWxhaW4uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpCZWhhdmUgbWFpbGluZyBsaXN0DQpCZWhhdmVAaWV0Zi5vcmc8bWFpbHRvOkJl aGF2ZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVo YXZlDQoNCg== From adurand@juniper.net Mon Nov 14 18:20:44 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2862811E8337 for ; Mon, 14 Nov 2011 18:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ddhXdN8kPNs for ; Mon, 14 Nov 2011 18:20:43 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB3511E8333 for ; Mon, 14 Nov 2011 18:20:40 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTsHMba5z1h6ibCZuVvvP31OXZc1EKae6@postini.com; Mon, 14 Nov 2011 18:20:40 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 14 Nov 2011 18:16:09 -0800 From: Alain Durand To: Marc Blanchet Date: Mon, 14 Nov 2011 18:16:08 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcyjPImVxl/k5puzRHW4YDP/BDcAig== Message-ID: <002C0C9A-4FA8-472A-B983-7544E6396398@juniper.net> References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> <7C55F961-6956-4A40-A916-44F20B6AA249@viagenie.ca> <5DCA01A5-43DF-4B7F-9D4D-20149AD46862@juniper.net> <48A63CA0-6A3D-4391-B061-DF4974293230@viagenie.ca> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "behave@ietf.org" , Behcet Sarikaya Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:20:44 -0000 T24gTm92IDE0LCAyMDExLCBhdCA5OjA4IFBNLCAiTWFyYyBCbGFuY2hldCIgPG1hcmMuYmxhbmNo ZXRAdmlhZ2VuaWUuY2E+IHdyb3RlOg0KDQo+IA0KPiBMZSAyMDExLTExLTE1IMOgIDEwOjA2LCBC ZWhjZXQgU2FyaWtheWEgYSDDqWNyaXQgOg0KPiANCj4+IEhpIE1hcmMsDQo+PiANCj4+IEkgdGhp bmsgdGhlIGFzc3VtcHRpb24gaXMgdGhhdCBlYWNoIENQRSBoYXMgYSBkaWZmZXJlbnQgV0FOIGFk ZHJlc3MuDQo+IA0KPiBpbmRlZWQuIEkgd2FzIGFzc3VtaW5nIGl0LiBNeSBxdWVzdGlvbiBpcyB0 aGUgYmVoYXZpb3Igb2YgdGhlIENHTiBpbiB0aGUgY2FzZSBiZWxvdy4gIExpa2Ugd2hlbiBhIENH TiBpcyBvdXQgb2YgcG9ydHMgZm9yIGFuIGVuZC11c2VyPw0KDQpJQ01QIGVycm9yLiBTZWUgZHJh ZnQgZm9yIGRldGFpbHMuDQoNCkFsYWluLg== From sarikaya2012@gmail.com Mon Nov 14 18:33:26 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DF011E8109 for ; Mon, 14 Nov 2011 18:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKEQ3Hn-AQRa for ; Mon, 14 Nov 2011 18:33:25 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D08411E8082 for ; Mon, 14 Nov 2011 18:33:25 -0800 (PST) Received: by ggnr5 with SMTP id r5so1843123ggn.31 for ; Mon, 14 Nov 2011 18:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RvFk2+Y90rvimRSIHzN4DZDqOveZm+HwX6qpxZX8jTM=; b=s+Xt9fobHPV6YpgDi69gp7bQFG9vhiOln+TdsrqyyVdI10asnrt/U7D2oTDmODbmSW WKEx/xcqHrWr4umm15PU1c9cQH9qPAFgQBSH7OPOCsuw3OYDbM3NFZ3w8cYI0xuAiE3z GpFgUUVOTLjL/CWAeWhBB/m5SPf7kUHCb/SJQ= MIME-Version: 1.0 Received: by 10.100.53.21 with SMTP id b21mr3456432ana.17.1321324402948; Mon, 14 Nov 2011 18:33:22 -0800 (PST) Received: by 10.236.191.228 with HTTP; Mon, 14 Nov 2011 18:33:22 -0800 (PST) In-Reply-To: References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> Date: Mon, 14 Nov 2011 20:33:22 -0600 Message-ID: From: Behcet Sarikaya To: Cameron Byrne Content-Type: multipart/alternative; boundary=0016e6471a90abbaa104b1bccfd7 Cc: "behave@ietf.org" , Alain Durand Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:33:26 -0000 --0016e6471a90abbaa104b1bccfd7 Content-Type: text/plain; charset=ISO-8859-1 I share Cameron's concerns here as this draft removes the nicest feature of DS-Lite: IPv6 only access network :-). Behcet On Mon, Nov 14, 2011 at 9:04 AM, Cameron Byrne wrote: > > On Nov 14, 2011 3:18 AM, "Alain Durand" wrote: > > > > Dear Behave wg: > > > > SD-NAT ( http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 ) was > presented today in Softwire and will be presented again in Behave on > Thursday. > > > > The overall feedback in Softwire was that SD-NAT is a stretch for this > wg and maybe Behave could be a better place as this is really CGN > optimization. So, I'd like to restart the discussion here on this mailling > list in preparation to the Behave meeting. > > > > ** So, what is SD-NAT and what problem does it solve? > > > > To deal with IPv4 exhaust, the commonly deployed approach today is IPv4 > address sharing, usually wih a CGN in NAT44 (or NAT444) if the access > network is IPv4 or with an AFTR in DS-Lite if the access network is IPv6. > The message that came loud and clear to the IETF community was that service > providers didn't like much having state and heavy logging in the middle of > the network. Techniques like deterministic NAT have addressed the logging > issue, but the state remains an issue. > > > > In a nutshell, SD-NAT is a way to make those CGNs stateless by > introducing a simple configuration change on the CPEs. > > > > > > ** What does a stateless CGN bring to the table? > > > > Having a stateless CGN means higher performance, lower delay, lower cost > and a very simple high availability solution. > > > > I have heard this several times but I have never seen these quantified > > I ask that the wg reject these assumptions until data is provided that > specifically support each of these claims with quantifiable deltas of > stateful vs stateless > > I am aware of the qualitative allure of stateless, but we should be data > driven. > > Cb > > > ** Related work > > > > A first answer was the so called 'stateless' approach in Softwire with > IPv4 address & port mapping. SD-NAT is another (much simpler) approach to > make the CGN stateless, without introducing this notion of address and port > mapping. It makes no assumption on what kind of network, IPv4 or IPv6 there > is on the access network. In the SD-NAT architecture, the CPE remains > essentially unchanged (modulo a new configuration parameter). Just like in > NAT44, NAT444 or DS-Lite, the CPE does not need the explicit knowledge of > which global IPv4 addres and port range it will be mapped to. > > > > > > ** How does SD-NAT work? > > > > The details are in the draft. At a hight level, the architecture relies > on the CPE to translate the src IP address to the one configured on it's > WAN interface (as usual), but not use the full [0-65535] port range, > instead use a limited range [1024-MaxPort]. That port range is the same for > all CPEs. > > Because this range is fixed and known by the CGN, the CGN can > programmatically map it to a global IPv4 address and port range by shifting > it's base IPv4/port by a customer ID multiplied by the number of ports > assigned per customers. > > > > All this is just shift/add/multiply on the CGN, there is no per session > state to maintain. > > > > - Alain. > > _______________________________________________ > > 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 > > --0016e6471a90abbaa104b1bccfd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I share Cameron's concerns here as this draft removes the nicest featur= e of DS-Lite: IPv6 only access network :-).

Behcet

On Mon, Nov 14, 2011 at 9:04 AM, Cameron Byrne <cb.list6@gmail.com&g= t; wrote:


On Nov 14, 2011 3:18 AM, "Alain Durand" <adurand@juniper.net> wrote:
>
> Dear Behave wg:
>
> SD-NAT ( http://tools.ietf.org/html/draft-penno-softwire-s= dnat-01 ) was presented today in Softwire and will be presented again i= n Behave on Thursday.
>
> The overall feedback in Softwire was that SD-NAT is a stretch for this= wg and maybe Behave could be a better place as this is really CGN optimiza= tion. So, I'd like to restart the discussion here on this mailling list= in preparation to the Behave meeting.
>
> ** So, what is SD-NAT and what problem does it solve?
>
> To deal with IPv4 exhaust, the commonly deployed approach today is IPv= 4 address sharing, usually wih a CGN in NAT44 (or NAT444) if the access net= work is IPv4 or with an AFTR in DS-Lite if the access network is IPv6. The = message that came loud and clear to the IETF community was that service pro= viders didn't like much having state and heavy logging in the middle of= the network. Techniques like deterministic NAT have addressed the logging = issue, but the state remains an issue.
>
> In a nutshell, SD-NAT is a way to make those CGNs stateless by introdu= cing a simple configuration change on the CPEs.
>
>
> ** What does a stateless CGN bring to the table?
>
> Having a stateless CGN means higher performance, lower delay, lower co= st and a very simple high availability solution.
>

I have heard this several times but I have never seen these quanti= fied

I ask that the wg reject these assumptions until data is provided that s= pecifically support each of these claims with quantifiable deltas of statef= ul vs stateless

I am aware of the qualitative allure of stateless, but we should be data= driven.

Cb

> ** Related work
>
> A first answer was the so called 'stateless' approach in Softw= ire with IPv4 address & port mapping. SD-NAT is another (much simpler) = approach to make the CGN stateless, without introducing this notion of addr= ess and port mapping. It makes no assumption on what kind of network, IPv4 = or IPv6 there is on the access network. In the SD-NAT architecture, the CPE= remains essentially unchanged (modulo a new configuration parameter). Just= like in NAT44, NAT444 or DS-Lite, the CPE does not need the explicit knowl= edge of which global IPv4 addres and port range it will be mapped to.
>
>
> ** How does SD-NAT work?
>
> The details are in the draft. At a hight level, the architecture relie= s on the CPE to translate the src IP address to the one configured on it= 9;s WAN interface (as usual), but not use the full [0-65535] port range, in= stead use a limited range [1024-MaxPort]. That port range is the same for a= ll CPEs.
> Because this range is fixed and known by the CGN, the CGN can programm= atically map it to a global IPv4 address and port range by shifting it'= s base IPv4/port by a customer ID multiplied by the number of ports assigne= d per customers.
>
> All this is just shift/add/multiply on the CGN, there is no per sessio= n state to maintain.
>
> =A0 - Alain.
> _______________________________________________
> 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


--0016e6471a90abbaa104b1bccfd7-- From adurand@juniper.net Mon Nov 14 18:42:54 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570DA11E80AE for ; Mon, 14 Nov 2011 18:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7BAJ1f4oeDm for ; Mon, 14 Nov 2011 18:42:54 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id AF2B711E8087 for ; Mon, 14 Nov 2011 18:42:53 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTsHRq4vgHhGr+D7hAdIC9nPbzfmCeas5@postini.com; Mon, 14 Nov 2011 18:42:53 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 14 Nov 2011 18:38:43 -0800 From: Alain Durand To: "sarikaya@ieee.org" Date: Mon, 14 Nov 2011 18:38:41 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcyjP7CF+flDEg0sTOqSKVW0sLc6gQ== Message-ID: References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cameron Byrne , "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:42:54 -0000 On Nov 15, 2011, at 10:33 AM, "Behcet Sarikaya" wr= ote: > I share Cameron's concerns here as this draft removes the nicest feature = of DS-Lite: IPv6 only access network :-). >=20 > Behcet Actually, SD-NAT works quite well with DS-Lite to make a stateless DS-Lite = solution. Details in the draft, but essentially all CPEs nat to 192.0.0.2 and the AFT= R use the IPv6 address of the CPE as customer ID. Alain.= From sarikaya2012@gmail.com Mon Nov 14 18:57:49 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9BD1F0D6A for ; Mon, 14 Nov 2011 18:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAYpN0BO4zYo for ; Mon, 14 Nov 2011 18:57:48 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BED5B1F0D3D for ; Mon, 14 Nov 2011 18:57:48 -0800 (PST) Received: by ggnr5 with SMTP id r5so1865902ggn.31 for ; Mon, 14 Nov 2011 18:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iLRkUJjdWBrQOTmtavOprM5MND57uizcWw5KSd9/GNk=; b=t30sRKafDlvR3h0K9/fqMvtlrT4Ytmk+zIH8j3Qtml8fUHnP6smZ5sv9nkZ6ngpxqE PMtVIRQbiB4eeZCi8qgfbMMSbXN2D1uVClEbBHaY7tsDvRGyP7Hrsuu2wcjtnQ/zD4Uv BGpmr7I6lfpt6/G1+Q7cVq1Qqxxjc9K0BV7R4= MIME-Version: 1.0 Received: by 10.147.116.9 with SMTP id t9mr3794023yam.5.1321325868113; Mon, 14 Nov 2011 18:57:48 -0800 (PST) Received: by 10.236.191.228 with HTTP; Mon, 14 Nov 2011 18:57:48 -0800 (PST) In-Reply-To: References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> Date: Mon, 14 Nov 2011 20:57:48 -0600 Message-ID: From: Behcet Sarikaya To: Alain Durand Content-Type: multipart/alternative; boundary=000e0cd567c200612704b1bd270a Cc: Cameron Byrne , "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:57:49 -0000 --000e0cd567c200612704b1bd270a Content-Type: text/plain; charset=ISO-8859-1 Without IPv6, DS-Lite becomes double NAT or NAT444. Behcet On Mon, Nov 14, 2011 at 8:38 PM, Alain Durand wrote: > On Nov 15, 2011, at 10:33 AM, "Behcet Sarikaya" > wrote: > > > I share Cameron's concerns here as this draft removes the nicest feature > of DS-Lite: IPv6 only access network :-). > > > > Behcet > > Actually, SD-NAT works quite well with DS-Lite to make a stateless DS-Lite > solution. > Details in the draft, but essentially all CPEs nat to 192.0.0.2 and the > AFTR use the IPv6 address of the CPE as customer ID. > > Alain. --000e0cd567c200612704b1bd270a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Without IPv6, DS-Lite becomes double NAT or NAT444.

Behcet

On Mon, Nov 14, 2011 at 8:38 PM, Alain Durand <adurand@juniper.ne= t> wrote:
On Nov 15, 2011, at 10:33= AM, "Behcet Sarikaya" <sarikaya2012@gmail.com> wrote:

> I share Cameron's concerns here as this draft removes the nicest f= eature of DS-Lite: IPv6 only access network :-).
>
> Behcet

Actually, SD-NAT works quite well with DS-Lite to make a stateless DS= -Lite solution.
Details in the draft, but essentially all CPEs nat to 192.0.0.2 and the AFT= R use the IPv6 address of the CPE as customer ID.

Alain.

--000e0cd567c200612704b1bd270a-- From adurand@juniper.net Mon Nov 14 19:19:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E6411E830B for ; Mon, 14 Nov 2011 19:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWKtHiYAyudn for ; Mon, 14 Nov 2011 19:19:11 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7A59711E82A3 for ; Mon, 14 Nov 2011 19:19:11 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTsHaLRDGmnrPjLE6F5EpmU6xSSWZbmYl@postini.com; Mon, 14 Nov 2011 19:19:11 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 14 Nov 2011 19:12:57 -0800 From: Alain Durand To: "sarikaya@ieee.org" Date: Mon, 14 Nov 2011 19:12:55 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcyjRHjjVGhFe6tKQnOysSlKc5vn4g== Message-ID: References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Cameron Byrne , "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 03:19:12 -0000 SSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4gYnkgJ3dpdGhvdXQgSVB2Nic/DQpJbiB0 aGUgcHJvcG9zYWwgaGVyZSB3aXRoIFNELURTLUxpdGUsIHRoZSBDUEVzIGFyZSBzdGlsbCBwcm92 aXNpb25lZCB3aXRoIElQdjYtb25seS4NCg0KQWxhaW4uDQoNClNlbnQgZnJvbSBteSBpUGFkDQoN Ck9uIE5vdiAxNSwgMjAxMSwgYXQgMTA6NTcgQU0sICJCZWhjZXQgU2FyaWtheWEiIDxzYXJpa2F5 YTIwMTJAZ21haWwuY29tPG1haWx0bzpzYXJpa2F5YTIwMTJAZ21haWwuY29tPj4gd3JvdGU6DQoN CldpdGhvdXQgSVB2NiwgRFMtTGl0ZSBiZWNvbWVzIGRvdWJsZSBOQVQgb3IgTkFUNDQ0Lg0KDQpC ZWhjZXQNCg0KT24gTW9uLCBOb3YgMTQsIDIwMTEgYXQgODozOCBQTSwgQWxhaW4gRHVyYW5kIDxh ZHVyYW5kQGp1bmlwZXIubmV0PG1haWx0bzphZHVyYW5kQGp1bmlwZXIubmV0Pj4gd3JvdGU6DQpP biBOb3YgMTUsIDIwMTEsIGF0IDEwOjMzIEFNLCAiQmVoY2V0IFNhcmlrYXlhIiA8c2FyaWtheWEy MDEyQGdtYWlsLmNvbTxtYWlsdG86c2FyaWtheWEyMDEyQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQo+ IEkgc2hhcmUgQ2FtZXJvbidzIGNvbmNlcm5zIGhlcmUgYXMgdGhpcyBkcmFmdCByZW1vdmVzIHRo ZSBuaWNlc3QgZmVhdHVyZSBvZiBEUy1MaXRlOiBJUHY2IG9ubHkgYWNjZXNzIG5ldHdvcmsgOi0p Lg0KPg0KPiBCZWhjZXQNCg0KQWN0dWFsbHksIFNELU5BVCB3b3JrcyBxdWl0ZSB3ZWxsIHdpdGgg RFMtTGl0ZSB0byBtYWtlIGEgc3RhdGVsZXNzIERTLUxpdGUgc29sdXRpb24uDQpEZXRhaWxzIGlu IHRoZSBkcmFmdCwgYnV0IGVzc2VudGlhbGx5IGFsbCBDUEVzIG5hdCB0byAxOTIuMC4wLjIgYW5k IHRoZSBBRlRSIHVzZSB0aGUgSVB2NiBhZGRyZXNzIG9mIHRoZSBDUEUgYXMgY3VzdG9tZXIgSUQu DQoNCkFsYWluLg0KDQo= From yiu_lee@cable.comcast.com Mon Nov 14 23:27:03 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839BF11E81D5 for ; Mon, 14 Nov 2011 23:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.222 X-Spam-Level: X-Spam-Status: No, score=-101.222 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxwXmQQFPLuV for ; Mon, 14 Nov 2011 23:27:03 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id EC53711E81E5 for ; Mon, 14 Nov 2011 23:27:02 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.61452295; Tue, 15 Nov 2011 00:27:06 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Tue, 15 Nov 2011 02:26:55 -0500 From: "Lee, Yiu" To: Alain Durand , "sarikaya@ieee.org" Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AQHMo2fzxJ/2E0kQLUmyLlY4P0ls0A== Date: Tue, 15 Nov 2011 07:26:54 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <41EBFEEFDBA40C46A6E50DF0C45F5D50@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cameron Byrne , "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 07:27:03 -0000 My understanding is if DS-NAT will need to do double-NAT when apply in DS-lite. This defeats one of the major advantage of DS-lite, doesn't it? On 11/14/11 10:12 PM, "Alain Durand" wrote: >I don't understand what you mean by 'without IPv6'? >In the proposal here with SD-DS-Lite, the CPEs are still provisioned with >IPv6-only. > >Alain. > >Sent from my iPad > >On Nov 15, 2011, at 10:57 AM, "Behcet Sarikaya" >> wrote: > >Without IPv6, DS-Lite becomes double NAT or NAT444. > >Behcet > >On Mon, Nov 14, 2011 at 8:38 PM, Alain Durand >> wrote: >On Nov 15, 2011, at 10:33 AM, "Behcet Sarikaya" >> wrote: > >> I share Cameron's concerns here as this draft removes the nicest >>feature of DS-Lite: IPv6 only access network :-). >> >> Behcet > >Actually, SD-NAT works quite well with DS-Lite to make a stateless >DS-Lite solution. >Details in the draft, but essentially all CPEs nat to 192.0.0.2 and the >AFTR use the IPv6 address of the CPE as customer ID. > >Alain. > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From ovautrin@juniper.net Tue Nov 15 00:09:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C749D11E80B6 for ; Tue, 15 Nov 2011 00:09:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx9AClYFQRDK for ; Tue, 15 Nov 2011 00:09:12 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 2464111E8081 for ; Tue, 15 Nov 2011 00:09:12 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTsIeJBukTwRVZ/Laziz/i4lNWV7gzxqi@postini.com; Tue, 15 Nov 2011 00:09:12 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 15 Nov 2011 00:00:00 -0800 From: Olivier Vautrin To: "Lee, Yiu" , Alain Durand , "sarikaya@ieee.org" Date: Mon, 14 Nov 2011 23:59:56 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcyjbJJrQceWoQDaSnminrhGpURHpw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cameron Byrne , "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 08:09:12 -0000 Yes. But you gain the advantage of having a Stateless AFTR. It is a tradeoff. /Olivier On 11/14/11 11:26 PM, "Lee, Yiu" wrote: >My understanding is if DS-NAT will need to do double-NAT when apply in >DS-lite. This defeats one of the major advantage of DS-lite, doesn't it? > > >On 11/14/11 10:12 PM, "Alain Durand" wrote: > >>I don't understand what you mean by 'without IPv6'? >>In the proposal here with SD-DS-Lite, the CPEs are still provisioned with >>IPv6-only. >> >>Alain. >> >>Sent from my iPad >> >>On Nov 15, 2011, at 10:57 AM, "Behcet Sarikaya" >>> wrote: >> >>Without IPv6, DS-Lite becomes double NAT or NAT444. >> >>Behcet >> >>On Mon, Nov 14, 2011 at 8:38 PM, Alain Durand >>> wrote: >>On Nov 15, 2011, at 10:33 AM, "Behcet Sarikaya" >>> wrote: >> >>> I share Cameron's concerns here as this draft removes the nicest >>>feature of DS-Lite: IPv6 only access network :-). >>> >>> Behcet >> >>Actually, SD-NAT works quite well with DS-Lite to make a stateless >>DS-Lite solution. >>Details in the draft, but essentially all CPEs nat to 192.0.0.2 and the >>AFTR use the IPv6 address of the CPE as customer ID. >> >>Alain. >> >>_______________________________________________ >>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 swmike@swm.pp.se Tue Nov 15 00:34:16 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BD721F8B0B for ; Tue, 15 Nov 2011 00:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6LIUIaJCW02 for ; Tue, 15 Nov 2011 00:34:15 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8224A21F8DC8 for ; Tue, 15 Nov 2011 00:34:08 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9C8149C; Tue, 15 Nov 2011 09:34:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 95DC89A; Tue, 15 Nov 2011 09:34:06 +0100 (CET) Date: Tue, 15 Nov 2011 09:34:06 +0100 (CET) From: Mikael Abrahamsson To: Cameron Byrne In-Reply-To: Message-ID: References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "behave@ietf.org" , Alain Durand Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 08:34:16 -0000 On Mon, 14 Nov 2011, Cameron Byrne wrote: > I ask that the wg reject these assumptions until data is provided that > specifically support each of these claims with quantifiable deltas of > stateful vs stateless > > I am aware of the qualitative allure of stateless, but we should be data > driven. I have one data point: A Cisco 7600 can to 6to4 at 10-15Mpps on the SUP because it's stateless, it'll do 128-256k flows of regular NAT, because it's stateful. There are network processor blades that does stateful NAT as well, they usually have limitations in the millions of flows and gigabits/s, whereas stateless solutions if properly implemented scales to 10x or more and no limitation in number of flows. I understand the "citation needed", but what kind of data do you need to feel that it's been quantified? -- Mikael Abrahamsson email: swmike@swm.pp.se From rpenno@juniper.net Tue Nov 15 01:03:28 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DEA21F8D4A for ; Tue, 15 Nov 2011 01:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJAkFbQwb4Rf for ; Tue, 15 Nov 2011 01:03:27 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 62AC621F8DD4 for ; Tue, 15 Nov 2011 01:03:26 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTsIq3fAtaOyBioRJkNmoqaTIkxup5Igf@postini.com; Tue, 15 Nov 2011 01:03:27 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 15 Nov 2011 00:57:08 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 15 Nov 2011 03:57:07 -0500 From: Reinaldo Penno To: Simon Perreault , "behave@ietf.org" Date: Tue, 15 Nov 2011 03:57:06 -0500 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcyjDcKsEP/JxQYgThq7dVPmK+iinQAZsl+g Message-ID: In-Reply-To: <4EC17CC4.1010204@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 09:03:28 -0000 How about this draft? http://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-00 It is the base premise of dozens of other drafts in softwires WG. Thanks, Reinaldo On 11/14/11 12:40 PM, "Simon Perreault" wrote= : > On 2011-11-15 00:04, Cameron Byrne wrote: >>> Having a stateless CGN means higher performance, lower delay, lower >> cost and a very simple high availability solution. >>>=20 >>=20 >> I have heard this several times but I have never seen these quantified >>=20 >> I ask that the wg reject these assumptions until data is provided that >> specifically support each of these claims with quantifiable deltas of >> stateful vs stateless >>=20 >> I am aware of the qualitative allure of stateless, but we should be data >> driven. >=20 > Well, simplicity and high availability are qualitative and any classical > networking textbook will demonstrate that stateless is better on these > two aspects. >=20 > I agree with you about the other claims (performance, delay, cost). >=20 > Simon From simon.perreault@viagenie.ca Tue Nov 15 06:26:16 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0273111E80D7 for ; Tue, 15 Nov 2011 06:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+PgFXGFKr9E for ; Tue, 15 Nov 2011 06:26:11 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E87F11E80A6 for ; Tue, 15 Nov 2011 06:26:10 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2B31F20C5E for ; Tue, 15 Nov 2011 09:25:40 -0500 (EST) Message-ID: <4EC27663.4020101@viagenie.ca> Date: Tue, 15 Nov 2011 09:25:39 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> In-Reply-To: <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 14:26:16 -0000 On 11/14/2011 08:23 PM, Alain Durand wrote: >> What % of existing CPEs can be remotely configured by the ISP to >> restrict the port range in this way? >> >> What % of existing CPEs cannot be configured remotely, but can be >> configured by the user to restrict the port range in this way? > > The functionality is part of the basic IPTABLES module on Linux. Even though many CPEs are based on Linux, many of them do not use iptables for their NAT functionality. Instead they have their own code or they use hardware-assisted NAT. So I'm not sure this argument has weight. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From bingxuere@gmail.com Tue Nov 15 17:46:34 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9D511E815E for ; Tue, 15 Nov 2011 17:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL-h67a4Onyz for ; Tue, 15 Nov 2011 17:46:30 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 081B711E815A for ; Tue, 15 Nov 2011 17:46:29 -0800 (PST) Received: by iaeo4 with SMTP id o4so11817460iae.31 for ; Tue, 15 Nov 2011 17:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BtJ9BWdE7c/EuT/Fv/LnfZZg93zTLc4OAlNjOt6b8OY=; b=SqOf3EAE8fj38J28ng07dglORi3cArjpqE5aLo/aMgRgVkoSTJ2Qsd84QiiKnO6Mhc hGY9GkvrvY1JQPiPG3UeZMAmiv1dAMkgJxupKPeQuqJGukmHU9NxJ+9Yywkr82ZgLkPd IVtOk9TkbDk+tU1O5uNZaSOdyhTAqkp054RZs= Received: by 10.42.147.72 with SMTP id m8mr30360322icv.56.1321407988264; Tue, 15 Nov 2011 17:46:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.223.197 with HTTP; Tue, 15 Nov 2011 17:45:47 -0800 (PST) In-Reply-To: References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> From: Qiong Date: Wed, 16 Nov 2011 09:45:47 +0800 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=90e6ba6e8b8ebe6dad04b1d0459c Cc: Alain Durand , Cameron Byrne , "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 01:46:34 -0000 --90e6ba6e8b8ebe6dad04b1d0459c Content-Type: text/plain; charset=UTF-8 Hi Mikael, I agree stateless is a good point in terms of scalability, reduced logging and cost, etc. And I think it is a reasonable model for NAT444 which can greatly reduce the burden of CGN. Best wishes Qiong On Tue, Nov 15, 2011 at 4:34 PM, Mikael Abrahamsson wrote: > On Mon, 14 Nov 2011, Cameron Byrne wrote: > > I ask that the wg reject these assumptions until data is provided that >> specifically support each of these claims with quantifiable deltas of >> stateful vs stateless >> >> I am aware of the qualitative allure of stateless, but we should be data >> driven. >> > > I have one data point: > > A Cisco 7600 can to 6to4 at 10-15Mpps on the SUP because it's stateless, > it'll do 128-256k flows of regular NAT, because it's stateful. > > There are network processor blades that does stateful NAT as well, they > usually have limitations in the millions of flows and gigabits/s, whereas > stateless solutions if properly implemented scales to 10x or more and no > limitation in number of flows. > > I understand the "citation needed", but what kind of data do you need to > feel that it's been quantified? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > ______________________________**_________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/**listinfo/behave > --90e6ba6e8b8ebe6dad04b1d0459c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi=C2=A0Mikael,

I agree stateless is a good point in ter= ms of scalability, reduced logging and cost, etc. And I think it is a reaso= nable model for NAT444 which can greatly reduce the burden of CGN.

Best wishes

Qiong

On Tue, Nov 15, 2011 at 4:34 PM, Mikael Abrahamsson <swmike@swm.pp.se>= ; wrote:
On Mon, 14 Nov 2011, Came= ron Byrne wrote:

I ask that the wg reject these assumptions until data is provided that spec= ifically support each of these claims with quantifiable deltas of stateful = vs stateless

I am aware of the qualitative allure of stateless, but we should be data dr= iven.

I have one data point:

A Cisco 7600 can to 6to4 at 10-15Mpps on the SUP because it's stateless= , it'll do 128-256k flows of regular NAT, because it's stateful.
There are network processor blades that does stateful NAT as well, they usu= ally have limitations in the millions of flows and gigabits/s, whereas stat= eless solutions if properly implemented scales to 10x or more and no limita= tion in number of flows.

I understand the "citation needed", but what kind of data do you = need to feel that it's been quantified?

--
Mikael Abrahamsson =C2=A0 =C2=A0email: swmike@swm.pp.se
<= div class=3D"h5">
_______________________________________________
Behave mailing list
Behave@ietf.org = https://www.ietf.org/mailman/listinfo/behave

--90e6ba6e8b8ebe6dad04b1d0459c-- From dwing@cisco.com Tue Nov 15 18:54:20 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE2311E81D0 for ; Tue, 15 Nov 2011 18:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.532 X-Spam-Level: X-Spam-Status: No, score=-104.532 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELMrDJrACgOQ for ; Tue, 15 Nov 2011 18:54:16 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id F320111E8164 for ; Tue, 15 Nov 2011 18:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1854; q=dns/txt; s=iport; t=1321412049; x=1322621649; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=nrrYFnaLd8HmvNe5i80ASOxpCjRJskLAkw6r7WsJRpc=; b=Op1HFsPet5ZoXAAmFmq1k9qXi/WT5VjQxtpP7BiF3jEkuaLeryszKsXg TPpHgA6j0okdLQRUKybRcLA+NqqWH4Wm69zOxnZ3KGBsdRBiaSu47niLS RS+79MqYAu4JyYqioig+YYHkvdhCanJviI08YM1IRbyIQQxAc8+AEEZ5J c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAAAQlw06rRDoG/2dsb2JhbABDmWqBao4edg+BcgEBAQMBAQEBBQoBFQIQNAsFBwEDAgkOAQIEAQEBJwcZDhUKCQgBAQQBEgsQB4dgCJpKAZ5VBIoXBIgShGcBmUM X-IronPort-AV: E=Sophos;i="4.69,518,1315180800"; d="scan'208";a="14526734" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 16 Nov 2011 02:54:06 +0000 Received: from dwingWS (sjc-vpn3-390.cisco.com [10.21.65.134]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAG2rd31028651; Wed, 16 Nov 2011 02:54:05 GMT From: "Dan Wing" To: "'Mikael Abrahamsson'" , "'Cameron Byrne'" References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> In-Reply-To: Date: Wed, 16 Nov 2011 10:53:38 +0800 Message-ID: <003701cca40b$01226a90$03673fb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyjcV8ojoIvHNigQYeu9/fto3OGOQAj/sfQ Content-Language: en-us Cc: 'Alain Durand' , behave@ietf.org Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 02:54:21 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Mikael Abrahamsson > Sent: Tuesday, November 15, 2011 4:34 PM > To: Cameron Byrne > Cc: behave@ietf.org; Alain Durand > Subject: Re: [BEHAVE] SD-NAT > > On Mon, 14 Nov 2011, Cameron Byrne wrote: > > > I ask that the wg reject these assumptions until data is provided > that > > specifically support each of these claims with quantifiable deltas of > > stateful vs stateless > > > > I am aware of the qualitative allure of stateless, but we should be > data > > driven. > > I have one data point: > > A Cisco 7600 can to 6to4 at 10-15Mpps on the SUP because it's > stateless, it'll do 128-256k flows of regular NAT, because > it's stateful. I understand the implementation of tunneling and NAT in that box is different, as well -- tunneled packets are processed in the interrupt path, whereas NATted packets are processed by punting the packets out of the interrupt path. This is always slower, but due to an implementation decision on that platform. As a counter-example, there are many $100 consumer-grade NATs which handle tens of megabits. They NAT packets in what is effectively their interrupt path. -d > There are network processor blades that does stateful NAT as well, they > usually have limitations in the millions of flows and gigabits/s, > whereas > stateless solutions if properly implemented scales to 10x or more and > no > limitation in number of flows. > > I understand the "citation needed", but what kind of data do you need > to > feel that it's been quantified? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From adurand@juniper.net Tue Nov 15 19:45:36 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773CE21F8F09 for ; Tue, 15 Nov 2011 19:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozF9fpMtoNws for ; Tue, 15 Nov 2011 19:45:35 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7B11F0C7F for ; Tue, 15 Nov 2011 19:45:35 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTsMx2cJ76ZdpfgohvAWHWejVHQHtVi8n@postini.com; Tue, 15 Nov 2011 19:45:35 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 15 Nov 2011 19:43:49 -0800 From: Alain Durand To: Dan Wing Date: Tue, 15 Nov 2011 19:43:29 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcykEfMLc1NstEMoT2Cm/b/rjDrkrg== Message-ID: <37D44455-C973-44C9-94D5-0D1380E6F2B5@juniper.net> References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <003701cca40b$01226a90$03673fb0$@com> In-Reply-To: <003701cca40b$01226a90$03673fb0$@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: Cameron Byrne , "behave@ietf.org" , Mikael Abrahamsson Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 03:45:36 -0000 On Nov 16, 2011, at 10:54 AM, "Dan Wing"=20 >=20 > As a counter-example, there are many $100 consumer-grade NATs=20 > which handle tens of megabits. They NAT packets in what > is effectively their interrupt path. The level of performance and reliability expected from those boxes is very = different than the ones expected for CGNs. In particular, there is no HA an= d things are not done at 10Gbps or more. Alain = From adurand@juniper.net Tue Nov 15 20:38:00 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713C211E8114 for ; Tue, 15 Nov 2011 20:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn0D2ys1MIwP for ; Tue, 15 Nov 2011 20:38:00 -0800 (PST) Received: from chip3og102.obsmtp.com (chip3og102.obsmtp.com [64.18.14.53]) by ietfa.amsl.com (Postfix) with ESMTP id B214811E8113 for ; Tue, 15 Nov 2011 20:37:59 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by chip3ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTsM+GU8zbTtGxDtuIH7BPbG6aTQDNiwb@postini.com; Tue, 15 Nov 2011 20:37:59 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 15 Nov 2011 20:35:07 -0800 From: Alain Durand To: "Lee, Yiu" Date: Tue, 15 Nov 2011 20:35:03 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcykGR2+7h8DgNDkRhye/7Blbjq7mA== Message-ID: <47B4C40F-2AE8-4E51-867E-2AC54E4A04A8@juniper.net> References: 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: "sarikaya@ieee.org" , "behave@ietf.org" , Cameron Byrne Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 04:38:00 -0000 On Nov 15, 2011, at 3:27 PM, "Lee, Yiu" wrote: > My understanding is if DS-NAT will need to do double-NAT when apply in > DS-lite. This defeats one of the major advantage of DS-lite, doesn't it? Actually, because the CGN is stateless, this is more a split NAT model than= a double NAT. Alain.= From yiu_lee@cable.comcast.com Tue Nov 15 22:17:17 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE8F11E8124 for ; Tue, 15 Nov 2011 22:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.049 X-Spam-Level: X-Spam-Status: No, score=-101.049 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JitgZfoeQJq8 for ; Tue, 15 Nov 2011 22:17:13 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id A3A8311E8130 for ; Tue, 15 Nov 2011 22:17:12 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.61620772; Tue, 15 Nov 2011 23:17:15 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Wed, 16 Nov 2011 01:17:04 -0500 From: "Lee, Yiu" To: Alain Durand Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcykGR2+c1NstEMoT2Cm/b/rjDrkrgADj3/R Date: Wed, 16 Nov 2011 06:17:03 +0000 Message-ID: <2AD10C3C-20FF-4ED8-BF8B-8B73D92586BE@Cable.Comcast.com> References: , <47B4C40F-2AE8-4E51-867E-2AC54E4A04A8@juniper.net> In-Reply-To: <47B4C40F-2AE8-4E51-867E-2AC54E4A04A8@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sarikaya@ieee.org" , "behave@ietf.org" , Cameron Byrne Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 06:17:18 -0000 I don't understand the difference between split NAT and double-NAT. Could y= ou please explain the difference? On Nov 15, 2011, at 11:38 PM, "Alain Durand" wrote: > On Nov 15, 2011, at 3:27 PM, "Lee, Yiu" wrote= : >=20 >> My understanding is if DS-NAT will need to do double-NAT when apply in >> DS-lite. This defeats one of the major advantage of DS-lite, doesn't it? >=20 > Actually, because the CGN is stateless, this is more a split NAT model th= an a double NAT. >=20 > Alain. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From nejc@skoberne.net Tue Nov 15 22:40:17 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1777A11E80FC for ; Tue, 15 Nov 2011 22:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cmbn7+w91G2N for ; Tue, 15 Nov 2011 22:40:14 -0800 (PST) Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9F611E819D for ; Tue, 15 Nov 2011 22:40:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id C77412278786 for ; Wed, 16 Nov 2011 07:39:50 +0100 (CET) Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bWvBGkkzeu7 for ; Wed, 16 Nov 2011 07:39:27 +0100 (CET) Received: from [130.129.21.42] (dhcp-152a.meeting.ietf.org [130.129.21.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 158D32278775 for ; Wed, 16 Nov 2011 07:39:18 +0100 (CET) Message-ID: <4EC35A8A.3070608@skoberne.net> Date: Wed, 16 Nov 2011 14:39:06 +0800 From: =?windows-1252?Q?Nejc_=8Akoberne?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: behave@ietf.org References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <4EC1A5C5.5060107@gmail.com> <74E02DD2-DE70-4A01-852F-9158B43BC7CA@juniper.net> <7A1E3CAC-BB1E-42CC-BF26-388938ECD93E@juniper.net> In-Reply-To: <7A1E3CAC-BB1E-42CC-BF26-388938ECD93E@juniper.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 06:40:17 -0000 Hi, >> Using this logic, deploying native ipv6 is trivial on home routers too, right? > > Not necessarily. > A number of ISP that provide CPE to their customers have told me that getting simple IPv4 patch for their vendor was relatively easy, getting IPv6 was much harder. I am really curious about this. Why would this be? I am really interested in the technical details. Thanks, Nejc From ovautrin@juniper.net Tue Nov 15 23:00:31 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4689911E81B7 for ; Tue, 15 Nov 2011 23:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.038 X-Spam-Level: X-Spam-Status: No, score=-6.038 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I81oGasHHtlX for ; Tue, 15 Nov 2011 23:00:27 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id B600811E81A1 for ; Tue, 15 Nov 2011 23:00:26 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTsNfhincF6SGd89Rs6VVWM77CBj1y7fp@postini.com; Tue, 15 Nov 2011 23:00:26 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 15 Nov 2011 22:55:49 -0800 From: Olivier Vautrin To: =?iso-8859-2?Q?Nejc_=A9koberne?= , "behave@ietf.org" Date: Tue, 15 Nov 2011 22:55:48 -0800 Thread-Topic: [BEHAVE] SD-NAT Thread-Index: AcykLMVRH0c6BB2XRI2nzLCIlOUdBg== Message-ID: In-Reply-To: <4EC35A8A.3070608@skoberne.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 07:00:31 -0000 As an example, I cannot install Ipv6 on my Linksys WAP54G at home because of memory limitation (cannot run the correct dd-wrt image). You can have a look here for the the different dd-wrt image size: http://www.dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F#File_Versions /Olivier On 11/16/11 2:39 PM, "Nejc =A9koberne" wrote: >Hi, > >>> Using this logic, deploying native ipv6 is trivial on home routers >>>too, right? >>=20 >> Not necessarily. >> A number of ISP that provide CPE to their customers have told me that >>getting simple IPv4 patch for their vendor was relatively easy, getting >>IPv6 was much harder. > >I am really curious about this. Why would this be? I am really interested >in the technical details. > >Thanks, >Nejc >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From swmike@swm.pp.se Tue Nov 15 23:28:25 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735EF11E8095 for ; Tue, 15 Nov 2011 23:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=-0.935, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjcsZSfrfXw9 for ; Tue, 15 Nov 2011 23:28:25 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C814221F9320 for ; Tue, 15 Nov 2011 23:28:23 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A2CC59C; Wed, 16 Nov 2011 08:28:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9B9AE9A; Wed, 16 Nov 2011 08:28:21 +0100 (CET) Date: Wed, 16 Nov 2011 08:28:21 +0100 (CET) From: Mikael Abrahamsson To: Dan Wing In-Reply-To: <003701cca40b$01226a90$03673fb0$@com> Message-ID: References: <01519A73-6EFB-4771-9FD3-1DE4EF084E8C@juniper.net> <003701cca40b$01226a90$03673fb0$@com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 'Alain Durand' , 'Cameron Byrne' , behave@ietf.org Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 07:28:25 -0000 On Wed, 16 Nov 2011, Dan Wing wrote: > As a counter-example, there are many $100 consumer-grade NATs which > handle tens of megabits. They NAT packets in what is effectively their > interrupt path. You're right, generally, stateless can be implemented in classic forwarding ASIC. Stateful needs to have CPUs to handle it. This generally means magnitudes of performance difference. -- Mikael Abrahamsson email: swmike@swm.pp.se From nejc@skoberne.net Wed Nov 16 03:21:13 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9115821F8D5B for ; Wed, 16 Nov 2011 03:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVk-A8PN0lZM for ; Wed, 16 Nov 2011 03:21:12 -0800 (PST) Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5C621F90C4 for ; Wed, 16 Nov 2011 03:21:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 85B3A2278006 for ; Wed, 16 Nov 2011 12:20:59 +0100 (CET) Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FemB8eKhxesg for ; Wed, 16 Nov 2011 12:20:17 +0100 (CET) Received: from [192.168.100.204] (61-220-70-183.HINET-IP.hinet.net [61.220.70.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 3E3C822780CA for ; Wed, 16 Nov 2011 12:19:55 +0100 (CET) Message-ID: <4EC39C56.9010102@skoberne.net> Date: Wed, 16 Nov 2011 19:19:50 +0800 From: =?ISO-8859-2?Q?Nejc_=A9koberne?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 11:21:13 -0000 Hi, > As an example, I cannot install Ipv6 on my Linksys WAP54G at home because > of memory limitation (cannot run the correct dd-wrt image). > > You can have a look here for the the different dd-wrt image size: > http://www.dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F#File_Versions Okay, if you need dd-wrt, that's true (and it's also true that WAP54G is a severly restricted piece of hardware). However, you could always run other less by-default-feature-rich distributions as OpenWRT? I am running a Whiterussian on a ASUS router with 2MB flash memory. WAP54G ver. >= 2 has 4MB of flash memory AFAIK ... Nejc From dean.cheng@huawei.com Wed Nov 16 06:23:18 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C98E21F9494 for ; Wed, 16 Nov 2011 06:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.041 X-Spam-Level: X-Spam-Status: No, score=-5.041 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzo3WtWK+bRg for ; Wed, 16 Nov 2011 06:23:17 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8970E21F947A for ; Wed, 16 Nov 2011 06:23:17 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUR00JLUBU1WU@szxga04-in.huawei.com> for behave@ietf.org; Wed, 16 Nov 2011 22:20:25 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUR00AY1BTDL0@szxga04-in.huawei.com> for behave@ietf.org; Wed, 16 Nov 2011 22:20:25 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA67233; Wed, 16 Nov 2011 22:20:17 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 22:20:12 +0800 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.67]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 22:19:44 +0800 Date: Wed, 16 Nov 2011 14:20:08 +0000 From: Dean cheng In-reply-to: <04EACFB6-BFB6-4BE8-B9A1-9606B6CF9AC5@juniper.net> X-Originating-IP: [10.47.138.228] To: Alain Durand , Simon Perreault Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [BEHAVE] SD-NAT Thread-index: Acyivp4t8BWfN4soSQGio0gHwZTdhP//uhcAgABd4wCAAEyKgP/9DMuw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 14:23:18 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Alain Durand > Sent: Monday, November 14, 2011 5:15 PM > To: Simon Perreault > Cc: behave@ietf.org > Subject: Re: [BEHAVE] SD-NAT > > On Nov 15, 2011, at 4:41 AM, "Simon Perreault" > wrote: > > > On 2011-11-15 00:04, Cameron Byrne wrote: > >>> Having a stateless CGN means higher performance, lower delay, lower > >> cost and a very simple high availability solution. > >>> > >> > >> I have heard this several times but I have never seen these quantified > >> > >> I ask that the wg reject these assumptions until data is provided that > >> specifically support each of these claims with quantifiable deltas of > >> stateful vs stateless > >> > >> I am aware of the qualitative allure of stateless, but we should be > data > >> driven. > > > > Well, simplicity and high availability are qualitative and any classical > > networking textbook will demonstrate that stateless is better on these > > two aspects. > > > > I agree with you about the other claims (performance, delay, cost). > > > > Simon > > On the boxes I'm familiar with, NAT/CGN is done on service cards. The > simple reason is that it requires lots of memory to keep the state. A > stateless solution would enable to move the implementation to the line > card and essentially do NAT at full lime rate. Huge difference. > > About high availability, doing fail-over of the full state table is > possible, but very expensive. In a stateless solution like SD-NAT, you > simply rely on anycast to achieve HA. See the draft for details. > > Alain. > Just want to add that even still with service cards, this solution has a significant advantage by eliminating logging on CGN that has been a big concern and new for ISP. Perfect things are rare in reality, but SD-NAT gives one more option for ISP when they have to deploy CGN. Dean > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From cb.list6@gmail.com Wed Nov 16 06:43:56 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E74F21F95F0 for ; Wed, 16 Nov 2011 06:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.078 X-Spam-Level: X-Spam-Status: No, score=-3.078 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZUB8hTKMuAl for ; Wed, 16 Nov 2011 06:43:52 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8FAC21F95E9 for ; Wed, 16 Nov 2011 06:43:51 -0800 (PST) Received: by eyg24 with SMTP id 24so607932eyg.31 for ; Wed, 16 Nov 2011 06:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2a1G5oV/C/+pUefUPLDxYstUtmAIyHwXbcTr5eKDefE=; b=CrSr1VS1CaDKEAcbp5zV2RsB2xIbs9aCGWnuIB3Bz1y2CWQ+FW4jlXUWXuHJWCkTVy gSkEKhkMV5KLQKjr5CU+wyVltFRZEIHmWrRULbEdxAeYbRDNxjgpSayLqOa29wGC3xMl yqnlp9wiY2xkJSRBRd5h6kI7wEXCjrIHW1J+c= MIME-Version: 1.0 Received: by 10.68.73.40 with SMTP id i8mr69776258pbv.45.1321454629894; Wed, 16 Nov 2011 06:43:49 -0800 (PST) Received: by 10.143.7.1 with HTTP; Wed, 16 Nov 2011 06:43:49 -0800 (PST) Received: by 10.143.7.1 with HTTP; Wed, 16 Nov 2011 06:43:49 -0800 (PST) In-Reply-To: References: <04EACFB6-BFB6-4BE8-B9A1-9606B6CF9AC5@juniper.net> Date: Wed, 16 Nov 2011 06:43:49 -0800 Message-ID: From: Cameron Byrne To: Dean cheng Content-Type: multipart/alternative; boundary=f46d04170701cd3a1204b1db210a Cc: Alain Durand , "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 14:43:56 -0000 --f46d04170701cd3a1204b1db210a Content-Type: text/plain; charset=ISO-8859-1 On Nov 16, 2011 6:23 AM, "Dean cheng" wrote: > > > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > > Of Alain Durand > > Sent: Monday, November 14, 2011 5:15 PM > > To: Simon Perreault > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] SD-NAT > > > > On Nov 15, 2011, at 4:41 AM, "Simon Perreault" > > wrote: > > > > > On 2011-11-15 00:04, Cameron Byrne wrote: > > >>> Having a stateless CGN means higher performance, lower delay, lower > > >> cost and a very simple high availability solution. > > >>> > > >> > > >> I have heard this several times but I have never seen these quantified > > >> > > >> I ask that the wg reject these assumptions until data is provided that > > >> specifically support each of these claims with quantifiable deltas of > > >> stateful vs stateless > > >> > > >> I am aware of the qualitative allure of stateless, but we should be > > data > > >> driven. > > > > > > Well, simplicity and high availability are qualitative and any classical > > > networking textbook will demonstrate that stateless is better on these > > > two aspects. > > > > > > I agree with you about the other claims (performance, delay, cost). > > > > > > Simon > > > > On the boxes I'm familiar with, NAT/CGN is done on service cards. The > > simple reason is that it requires lots of memory to keep the state. A > > stateless solution would enable to move the implementation to the line > > card and essentially do NAT at full lime rate. Huge difference. > > > > About high availability, doing fail-over of the full state table is > > possible, but very expensive. In a stateless solution like SD-NAT, you > > simply rely on anycast to achieve HA. See the draft for details. > > > > Alain. > > > > Just want to add that even still with service cards, this solution has a significant advantage by eliminating logging on CGN that has been a big concern and new for ISP. Perfect things are rare in reality, but SD-NAT gives one more option for ISP when they have to deploy CGN. > Right. More is better , right ? Cb > Dean > > > > > > _______________________________________________ > > 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 --f46d04170701cd3a1204b1db210a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 16, 2011 6:23 AM, "Dean cheng" <dean.cheng@huawei.com> wrote:
>
>
>
> > -----Original Message-----
> > From: behave-bounces@i= etf.org [mailto:behave-bounc= es@ietf.org] On Behalf
> > Of Alain Durand
> > Sent: Monday, November 14, 2011 5:15 PM
> > To: Simon Perreault
> > Cc: behave@ietf.org
> > Subject: Re: [BEHAVE] SD-NAT
> >
> > On Nov 15, 2011, at 4:41 AM, "Simon Perreault"
> > <simon.perreaul= t@viagenie.ca> wrote:
> >
> > > On 2011-11-15 00:04, Cameron Byrne wrote:
> > >>> Having a stateless CGN means higher performance, low= er delay, lower
> > >> cost and a very simple high availability solution.
> > >>>
> > >>
> > >> I have heard this several times but I have never seen th= ese quantified
> > >>
> > >> I ask that the wg reject these assumptions until data is= provided that
> > >> specifically support each of these claims with quantifia= ble deltas of
> > >> stateful vs stateless
> > >>
> > >> I am aware of the qualitative allure of stateless, but w= e should be
> > data
> > >> driven.
> > >
> > > Well, simplicity and high availability are qualitative and a= ny classical
> > > networking textbook will demonstrate that stateless is bette= r on these
> > > two aspects.
> > >
> > > I agree with you about the other claims (performance, delay,= cost).
> > >
> > > Simon
> >
> > On the boxes I'm familiar with, NAT/CGN is done on service ca= rds. The
> > simple reason is that it requires lots of memory to keep the stat= e. A
> > stateless solution would enable to move the implementation to the= line
> > card and essentially do NAT at full lime rate. Huge difference. > >
> > About high availability, doing fail-over of the full state table = is
> > possible, but very expensive. In a stateless solution like SD-NAT= , you
> > simply rely on anycast to achieve HA. See the draft for details.<= br> > >
> > Alain.
> >
>
> Just want to add that even still with service cards, this solution has= a significant advantage by eliminating logging on CGN that has been a big = concern and new for ISP. Perfect things are rare in reality, but SD-NAT giv= es one more option for ISP when they have to deploy CGN.
>

Right. More is better , right ?

Cb

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

--f46d04170701cd3a1204b1db210a-- From dean.cheng@huawei.com Tue Nov 15 16:02:47 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9C311E8147 for ; Tue, 15 Nov 2011 16:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.56 X-Spam-Level: X-Spam-Status: No, score=-5.56 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SE628XXdEW9 for ; Tue, 15 Nov 2011 16:02:46 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 69B6111E8137 for ; Tue, 15 Nov 2011 16:02:46 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00D7T84D9E@szxga05-in.huawei.com> for behave@ietf.org; Wed, 16 Nov 2011 08:02:37 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ008BN84COK@szxga05-in.huawei.com> for behave@ietf.org; Wed, 16 Nov 2011 08:02:37 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFB58598; Wed, 16 Nov 2011 08:02:36 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 08:02:32 +0800 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.67]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 08:02:29 +0800 Date: Wed, 16 Nov 2011 00:02:28 +0000 From: Dean cheng In-reply-to: <04EACFB6-BFB6-4BE8-B9A1-9606B6CF9AC5@juniper.net> X-Originating-IP: [10.47.131.155] To: Alain Durand , Simon Perreault Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [BEHAVE] SD-NAT Thread-index: Acyivp4t8BWfN4soSQGio0gHwZTdhP//uhcAgABd4wCAAEyKgP/9/zUg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 16 Nov 2011 16:26:24 -0800 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] SD-NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 00:02:47 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Alain Durand > Sent: Monday, November 14, 2011 5:15 PM > To: Simon Perreault > Cc: behave@ietf.org > Subject: Re: [BEHAVE] SD-NAT > > On Nov 15, 2011, at 4:41 AM, "Simon Perreault" > wrote: > > > On 2011-11-15 00:04, Cameron Byrne wrote: > >>> Having a stateless CGN means higher performance, lower delay, lower > >> cost and a very simple high availability solution. > >>> > >> > >> I have heard this several times but I have never seen these quantified > >> > >> I ask that the wg reject these assumptions until data is provided that > >> specifically support each of these claims with quantifiable deltas of > >> stateful vs stateless > >> > >> I am aware of the qualitative allure of stateless, but we should be > data > >> driven. > > > > Well, simplicity and high availability are qualitative and any classical > > networking textbook will demonstrate that stateless is better on these > > two aspects. > > > > I agree with you about the other claims (performance, delay, cost). > > > > Simon > > On the boxes I'm familiar with, NAT/CGN is done on service cards. The > simple reason is that it requires lots of memory to keep the state. A > stateless solution would enable to move the implementation to the line > card and essentially do NAT at full lime rate. Huge difference. > > About high availability, doing fail-over of the full state table is > possible, but very expensive. In a stateless solution like SD-NAT, you > simply rely on anycast to achieve HA. See the draft for details. > > Alain. Just want to add that even still with service cards, this solution has a significant advantage by eliminating logging on CGN that has been a big concern and new for ISP. Perfect things are rare in reality, but SD-NAT gives one more option for ISP when they have to deploy CGN. Dean > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rpenno@juniper.net Wed Nov 16 17:12:44 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AFA21F8EA4 for ; Wed, 16 Nov 2011 17:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCSI8WFGYsDr for ; Wed, 16 Nov 2011 17:12:44 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 20D9821F8B0E for ; Wed, 16 Nov 2011 17:12:44 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTsRfi6+GQlcPt0TtER/IFc0ctVC2m9yc@postini.com; Wed, 16 Nov 2011 17:12:44 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 16 Nov 2011 17:10:58 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 16 Nov 2011 20:10:57 -0500 From: Reinaldo Penno To: "behave@ietf.org" Date: Wed, 16 Nov 2011 20:10:54 -0500 Thread-Topic: Updated http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-02 Thread-Index: Acyivp4t8BWfN4soSQGio0gHwZTdhP//uhcAgABd4wCAAEyKgP/9/zUg//pVc8I= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Updated http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:12:45 -0000 Updated based on comments from Senthil and others. Thanks, Reinaldo From ajs@anvilwalrusden.com Thu Nov 17 00:55:43 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411AA21F9A9F for ; Thu, 17 Nov 2011 00:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22G79XOL2vgr for ; Thu, 17 Nov 2011 00:55:42 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B25C021F9A99 for ; Thu, 17 Nov 2011 00:55:42 -0800 (PST) Received: from shinkuro.com (dhcp-2535.meeting.ietf.org [130.129.37.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7ED5E1ECB422 for ; Thu, 17 Nov 2011 08:55:27 +0000 (UTC) Date: Thu, 17 Nov 2011 03:55:35 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20111117085534.GD35001@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [BEHAVE] My remark about CGN logging in today's meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 08:55:43 -0000 Hi, So that I don't keep getting up and saying this at the mic, the point that I was trying to make about the CGN stuff today was not that CGNs are evil or wrong or whatever. It was, rather, that if we are serious about not continuing with the "life support" strategy that we heard about in the INT area meeting, and if we think that the IETF should do that partly by just not working on anything that makes life support work, then we have to discipline ourselves not to take on work that is primarily aimed at making life easier with transition strategies that do not lead towards retiring IPv4. CGNs do absolutely nothing in the direction of encouraging moving to IPv6, nor in the discouragement of IPv4. Making the logging problems of running CGNs less severe is, therefore, not going to discourage IPv4 nor promote IPv6. Offering advice for how to deploy CGNs does not discourage their deployment. I don't know whether I think the strategy of "Just say no" will work. That was, after all, the original answer to doing NAT at all, and it didn't work. Certainly the DNS community has been trying to say no for years, and that has been a massive failure. But if we're actually going to adopt a "Just say no" strategy, then some of the CGN drafts are the sorts of things that will have to be rejected, and I therefore don't think they should become WG items at least until we have decided whether the "No" strategy is a good idea. Otherwise, we'll be declaring that we think we should not stop work on the life support strategies. A -- Andrew Sullivan ajs@anvilwalrusden.com From hannes.tschofenig@gmx.net Thu Nov 17 02:16:51 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EAB21F9BA8 for ; Thu, 17 Nov 2011 02:16:51 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFsLdanas2nU for ; Thu, 17 Nov 2011 02:16:50 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 67FD421F9BA9 for ; Thu, 17 Nov 2011 02:16:50 -0800 (PST) Received: (qmail invoked by alias); 17 Nov 2011 10:16:48 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp065) with SMTP; 17 Nov 2011 11:16:48 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/VrqNCL57V1hO9BzFOLfdAWZOCOdwzxJwck5aMD8 73AhStMSFKdMY3 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <20111117085534.GD35001@shinkuro.com> Date: Thu, 17 Nov 2011 11:16:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4E70F0AC-FC4C-4624-98B6-137193633D51@gmx.net> References: <20111117085534.GD35001@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: behave@ietf.org Subject: Re: [BEHAVE] My remark about CGN logging in today's meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 10:16:51 -0000 Andrew, I completely agree with you.=20 Being consistent is just fair. It is not OK to suggest to discontinue = other people's work but than in the next second to suggest new work that = is in contradiction.=20 For example, in the Intarea meeting Dan Wing argued that we have to = provide "life support" to deal with the issues caused by address sharing = due to CGNs by working on = draft-boucadair-intarea-nat-reveal-analysis-04. Then, a few minutes = later he gives a presentation and argues to discontinue work that = focuses on life support. Ciao Hannes On Nov 17, 2011, at 9:55 AM, Andrew Sullivan wrote: > Hi, >=20 > So that I don't keep getting up and saying this at the mic, the point > that I was trying to make about the CGN stuff today was not that CGNs > are evil or wrong or whatever. >=20 > It was, rather, that if we are serious about not continuing with the > "life support" strategy that we heard about in the INT area meeting, > and if we think that the IETF should do that partly by just not > working on anything that makes life support work, then we have to > discipline ourselves not to take on work that is primarily aimed at > making life easier with transition strategies that do not lead towards > retiring IPv4. >=20 > CGNs do absolutely nothing in the direction of encouraging moving to > IPv6, nor in the discouragement of IPv4. Making the logging problems > of running CGNs less severe is, therefore, not going to discourage > IPv4 nor promote IPv6. Offering advice for how to deploy CGNs does > not discourage their deployment. >=20 > I don't know whether I think the strategy of "Just say no" will work. > That was, after all, the original answer to doing NAT at all, and it > didn't work. Certainly the DNS community has been trying to say no > for years, and that has been a massive failure. But if we're actually > going to adopt a "Just say no" strategy, then some of the CGN drafts > are the sorts of things that will have to be rejected, and I therefore > don't think they should become WG items at least until we have decided > whether the "No" strategy is a good idea. Otherwise, we'll be > declaring that we think we should not stop work on the life support > strategies. >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From cb.list6@gmail.com Thu Nov 17 06:27:43 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F9F11E8148 for ; Thu, 17 Nov 2011 06:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.095 X-Spam-Level: X-Spam-Status: No, score=-3.095 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTB6Lk0EOS5d for ; Thu, 17 Nov 2011 06:27:43 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFBF811E8128 for ; Thu, 17 Nov 2011 06:27:42 -0800 (PST) Received: by iaeo4 with SMTP id o4so2669767iae.31 for ; Thu, 17 Nov 2011 06:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4F59BhQnVqHTe0FWbgvvC8nswO3amRB5Of4YBQMsT6I=; b=tkhmNnkt3iVON7x26EZMvMsKPBDRNfSDpXU2r4uuKltyQqQcLyOmFhGitboHKSVTci BaMsE05n/pzLGOJOSB3zye227yrTdFZVtRFW3BB2CTekqXObbt+bdpD6ib26M94MNJZw rPv1ZvOgw27NBfSn4BD6i0lADqIxKYP4Cn9/8= MIME-Version: 1.0 Received: by 10.231.46.66 with SMTP id i2mr9817566ibf.0.1321540062050; Thu, 17 Nov 2011 06:27:42 -0800 (PST) Received: by 10.143.7.1 with HTTP; Thu, 17 Nov 2011 06:27:41 -0800 (PST) Received: by 10.143.7.1 with HTTP; Thu, 17 Nov 2011 06:27:41 -0800 (PST) In-Reply-To: <4E70F0AC-FC4C-4624-98B6-137193633D51@gmx.net> References: <20111117085534.GD35001@shinkuro.com> <4E70F0AC-FC4C-4624-98B6-137193633D51@gmx.net> Date: Thu, 17 Nov 2011 06:27:41 -0800 Message-ID: From: Cameron Byrne To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001517740abaf47bea04b1ef05f4 Cc: behave@ietf.org, Andrew Sullivan Subject: Re: [BEHAVE] My remark about CGN logging in today's meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 14:27:43 -0000 --001517740abaf47bea04b1ef05f4 Content-Type: text/plain; charset=ISO-8859-1 On Nov 17, 2011 2:17 AM, "Hannes Tschofenig" wrote: > > Andrew, I completely agree with you. > I also agree. But I think we are on the wrong list. I may be wrong, but imho it is softwire that is in overdrive. I would love to say that 6rd, dslite, and Nat64/DNS64 are the menu, now go deploy. Any rough edges in any of these have a clear long term solution, do more v6. Cb > Being consistent is just fair. It is not OK to suggest to discontinue other people's work but than in the next second to suggest new work that is in contradiction. > > For example, in the Intarea meeting Dan Wing argued that we have to provide "life support" to deal with the issues caused by address sharing due to CGNs by working on draft-boucadair-intarea-nat-reveal-analysis-04. Then, a few minutes later he gives a presentation and argues to discontinue work that focuses on life support. > > Ciao > Hannes > > On Nov 17, 2011, at 9:55 AM, Andrew Sullivan wrote: > > > Hi, > > > > So that I don't keep getting up and saying this at the mic, the point > > that I was trying to make about the CGN stuff today was not that CGNs > > are evil or wrong or whatever. > > > > It was, rather, that if we are serious about not continuing with the > > "life support" strategy that we heard about in the INT area meeting, > > and if we think that the IETF should do that partly by just not > > working on anything that makes life support work, then we have to > > discipline ourselves not to take on work that is primarily aimed at > > making life easier with transition strategies that do not lead towards > > retiring IPv4. > > > > CGNs do absolutely nothing in the direction of encouraging moving to > > IPv6, nor in the discouragement of IPv4. Making the logging problems > > of running CGNs less severe is, therefore, not going to discourage > > IPv4 nor promote IPv6. Offering advice for how to deploy CGNs does > > not discourage their deployment. > > > > I don't know whether I think the strategy of "Just say no" will work. > > That was, after all, the original answer to doing NAT at all, and it > > didn't work. Certainly the DNS community has been trying to say no > > for years, and that has been a massive failure. But if we're actually > > going to adopt a "Just say no" strategy, then some of the CGN drafts > > are the sorts of things that will have to be rejected, and I therefore > > don't think they should become WG items at least until we have decided > > whether the "No" strategy is a good idea. Otherwise, we'll be > > declaring that we think we should not stop work on the life support > > strategies. > > > > A > > > > -- > > Andrew Sullivan > > ajs@anvilwalrusden.com > > _______________________________________________ > > 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 --001517740abaf47bea04b1ef05f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 17, 2011 2:17 AM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net> wrote:
>
> Andrew, I completely agree with you.
>

I also agree. But I think we are on the wrong list.=A0 I may be wrong, b= ut imho it is softwire that is in overdrive.

I would love to say that 6rd, dslite, and Nat64/DNS64 are the menu, now = go deploy. Any rough edges in any of these have a clear long term solution,= do more v6.=A0

Cb

> Being consistent is just fair. It is not OK to suggest to discontin= ue other people's work but than in the next second to suggest new work = that is in contradiction.
>
> For example, in the Intarea meeting Dan Wing argued that we have to pr= ovide "life support" to deal with the issues caused by address sh= aring due to CGNs by working on draft-boucadair-intarea-nat-reveal-analysis= -04. Then, a few minutes later he gives a presentation and argues to discon= tinue work that focuses on life support.
>
> Ciao
> Hannes
>
> On Nov 17, 2011, at 9:55 AM, Andrew Sullivan wrote:
>
> > Hi,
> >
> > So that I don't keep getting up and saying this at the mic, t= he point
> > that I was trying to make about the CGN stuff today was not that = CGNs
> > are evil or wrong or whatever.
> >
> > It was, rather, that if we are serious about not continuing with = the
> > "life support" strategy that we heard about in the INT = area meeting,
> > and if we think that the IETF should do that partly by just not > > working on anything that makes life support work, then we have to=
> > discipline ourselves not to take on work that is primarily aimed = at
> > making life easier with transition strategies that do not lead to= wards
> > retiring IPv4.
> >
> > CGNs do absolutely nothing in the direction of encouraging moving= to
> > IPv6, nor in the discouragement of IPv4. =A0Making the logging pr= oblems
> > of running CGNs less severe is, therefore, not going to discourag= e
> > IPv4 nor promote IPv6. =A0Offering advice for how to deploy CGNs = does
> > not discourage their deployment.
> >
> > I don't know whether I think the strategy of "Just say n= o" will work.
> > That was, after all, the original answer to doing NAT at all, and= it
> > didn't work. =A0Certainly the DNS community has been trying t= o say no
> > for years, and that has been a massive failure. =A0But if we'= re actually
> > going to adopt a "Just say no" strategy, then some of t= he CGN drafts
> > are the sorts of things that will have to be rejected, and I ther= efore
> > don't think they should become WG items at least until we hav= e decided
> > whether the "No" strategy is a good idea. =A0Otherwise,= we'll be
> > declaring that we think we should not stop work on the life suppo= rt
> > strategies.
> >
> > A
> >
> > --
> > Andrew Sullivan
> > ajs@anvilwalrusden.com<= /a>
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://= www.ietf.org/mailman/listinfo/behave
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave

--001517740abaf47bea04b1ef05f4-- From nejc@skoberne.net Thu Nov 17 10:46:36 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEBE21F9895 for ; Thu, 17 Nov 2011 10:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f59lcmM6V8Sq for ; Thu, 17 Nov 2011 10:46:35 -0800 (PST) Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id BE35621F986A for ; Thu, 17 Nov 2011 10:46:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 67005227881E for ; Thu, 17 Nov 2011 19:46:32 +0100 (CET) Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDpXnGG0fT8f for ; Thu, 17 Nov 2011 19:46:31 +0100 (CET) Received: from [192.168.100.204] (61-220-70-183.HINET-IP.hinet.net [61.220.70.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id DDE6F227881B for ; Thu, 17 Nov 2011 19:46:16 +0100 (CET) Message-ID: <4EC55672.9030703@skoberne.net> Date: Fri, 18 Nov 2011 02:46:10 +0800 From: =?windows-1252?Q?Nejc_=8Akoberne?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: behave@ietf.org References: <20111117085534.GD35001@shinkuro.com> In-Reply-To: <20111117085534.GD35001@shinkuro.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] My remark about CGN logging in today's meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 18:46:36 -0000 Hi, > It was, rather, that if we are serious about not continuing with the > "life support" strategy that we heard about in the INT area meeting, > and if we think that the IETF should do that partly by just not > working on anything that makes life support work, then we have to > discipline ourselves not to take on work that is primarily aimed at > making life easier with transition strategies that do not lead towards > retiring IPv4. I strongly agree. I think that IETF should not be the place to work on IPv4 "life support" strategies (any more). I felt that yesterday at intarea there was (at least) a "rough consensus" for this direction by most of the people there. Also, I think that if there really is such a consensus, that it would make sense for IETF to make an "official" stand on this (if there isn't one yet and if that's even possible). > CGNs do absolutely nothing in the direction of encouraging moving to > IPv6, nor in the discouragement of IPv4. Making the logging problems > of running CGNs less severe is, therefore, not going to discourage > IPv4 nor promote IPv6. Offering advice for how to deploy CGNs does > not discourage their deployment. Here, I partly disagree. IMHO, CGN in general stands for "the NAT function is located in the ISP network". NAT64 and DS-Lite are also examples of CGN technologies, yet they are encouraging moving to IPv6 at least to some extent (DS-Lite in the access network, NAT64 in the end-user network). So I think there are significant differences among various CGN technologies. It is quite simple, I think. Those, which in any way contribute to making IPv4-only life easier, should not be considered anymore (at least not in the IETF). If we want people to start working harder on IPv6, we have to let IPv4-only life be as hard as it is. Anyway, people will do whatever they please in the end. All IETF can do to push things in the right (IPv6) direction is not to work on things, which deviate from this direction (IPv4-only(-allowing)). > I don't know whether I think the strategy of "Just say no" will work. > That was, after all, the original answer to doing NAT at all, and it > didn't work. Certainly the DNS community has been trying to say no > for years, and that has been a massive failure. But if we're actually > going to adopt a "Just say no" strategy, then some of the CGN drafts > are the sorts of things that will have to be rejected, and I therefore > don't think they should become WG items at least until we have decided > whether the "No" strategy is a good idea. Otherwise, we'll be > declaring that we think we should not stop work on the life support > strategies. I agree. Regards, Nejc From nejc@skoberne.net Thu Nov 17 10:55:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA8E21F995C for ; Thu, 17 Nov 2011 10:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+os0PGW2w0g for ; Thu, 17 Nov 2011 10:55:11 -0800 (PST) Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id BED8021F995E for ; Thu, 17 Nov 2011 10:55:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id D56E222787B8 for ; Thu, 17 Nov 2011 19:55:10 +0100 (CET) Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxpwCoQ4fu-d for ; Thu, 17 Nov 2011 19:55:10 +0100 (CET) Received: from [192.168.100.204] (61-220-70-183.HINET-IP.hinet.net [61.220.70.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id A8B7C227879D for ; Thu, 17 Nov 2011 19:55:09 +0100 (CET) Message-ID: <4EC55889.30201@skoberne.net> Date: Fri, 18 Nov 2011 02:55:05 +0800 From: =?windows-1252?Q?Nejc_=8Akoberne?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: behave@ietf.org References: <20111117085534.GD35001@shinkuro.com> <4E70F0AC-FC4C-4624-98B6-137193633D51@gmx.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] My remark about CGN logging in today's meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 18:55:12 -0000 Hi, > I also agree. But I think we are on the wrong list. I may be wrong, but > imho it is softwire that is in overdrive. SD-NAT was (also) presented at BEHAVE today at IETF 82. It makes IPv4-only CGNs' lives easier by providing statelessness for them. I know, the authors say it is "mechanism-agnostic". Well, if it is, then it should be made "mechanism gnostic" and allow for IPv6 transition mechanisms only. Nejc From dwing@cisco.com Thu Nov 17 18:04:07 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF4611E80B5 for ; Thu, 17 Nov 2011 18:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.761 X-Spam-Level: X-Spam-Status: No, score=-105.761 tagged_above=-999 required=5 tests=[AWL=0.838, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVzzEouOt3dZ for ; Thu, 17 Nov 2011 18:04:06 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C261F11E808A for ; Thu, 17 Nov 2011 18:04:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3624; q=dns/txt; s=iport; t=1321581846; x=1322791446; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=x90klC84y6dppoh5nwDM8b8GBp5iTCe5ozrysmuIzZY=; b=ErigTwhTF5CshW5zd6vsmJ/MeRGEI6ubaofuEYAiy8wzXRfs/Yo2NrYc ZJblrUeZENbrNJK5NDhq6tvUoZHbtypDHPq1nCOVPwYt70+gT/DGhyt8L 6cVjxsOt6KP4y/PGFZrw5KKicGlmqw/CVeun6+henezMFHbJnbWO4lntP E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoAAMq8xU6rRDoG/2dsb2JhbABCmhGBao5IgQWBcgEBAQECAQEBAQUKARcQNAsFBwEDAgkPAgQBAQEnBxkOFQoJCAEBBAESCwkFCYdgCJgQAZ4qBIoXBIgThEAnAZlD X-IronPort-AV: E=Sophos;i="4.69,530,1315180800"; d="scan'208";a="13227425" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 18 Nov 2011 02:04:06 +0000 Received: from dwingWS (sjc-vpn5-1723.cisco.com [10.21.94.187]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAI245uQ025757; Fri, 18 Nov 2011 02:04:05 GMT From: "Dan Wing" To: "'Hannes Tschofenig'" , "'Andrew Sullivan'" References: <20111117085534.GD35001@shinkuro.com> <4E70F0AC-FC4C-4624-98B6-137193633D51@gmx.net> In-Reply-To: <4E70F0AC-FC4C-4624-98B6-137193633D51@gmx.net> Date: Fri, 18 Nov 2011 10:04:04 +0800 Message-ID: <02e201cca596$5a1ba3a0$0e52eae0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcylEhIvB6NkW/g+SeuZjzsNxTiecQAg6h/g Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] My remark about CGN logging in today's meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 02:04:07 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: Thursday, November 17, 2011 6:17 PM > To: Andrew Sullivan > Cc: behave@ietf.org > Subject: Re: [BEHAVE] My remark about CGN logging in today's meeting > > Andrew, I completely agree with you. > > Being consistent is just fair. It is not OK to suggest to discontinue > other people's work but than in the next second to suggest new work > that is in contradiction. > > For example, in the Intarea meeting Dan Wing argued that we have to > provide "life support" to deal with the issues caused by address > sharing due to CGNs by working on draft-boucadair-intarea-nat-reveal- > analysis-04. draft-boucadair-intarea-nat-reveal-analysis is necessary to distinguish between good guys and bad guys with any address sharing, including NAT64, 4rd, dIVI, A+P, and others. Such address sharing will be necessary so long as there are IPv4 servers on the Internet. The problem only goes away when the Good Guys (legitimate users) are running IPv6 and the servers they are accessing support IPv6. The attackers will use address sharing if address sharing gives them an attack advantage. draft-boucadair-intarea-nat-reveal-analysis shows mechanisms to eliminate this attack advantage. -d > Then, a few minutes later he gives a presentation and > argues to discontinue work that focuses on life support. > > Ciao > Hannes > > On Nov 17, 2011, at 9:55 AM, Andrew Sullivan wrote: > > > Hi, > > > > So that I don't keep getting up and saying this at the mic, the point > > that I was trying to make about the CGN stuff today was not that CGNs > > are evil or wrong or whatever. > > > > It was, rather, that if we are serious about not continuing with the > > "life support" strategy that we heard about in the INT area meeting, > > and if we think that the IETF should do that partly by just not > > working on anything that makes life support work, then we have to > > discipline ourselves not to take on work that is primarily aimed at > > making life easier with transition strategies that do not lead > towards > > retiring IPv4. > > > > CGNs do absolutely nothing in the direction of encouraging moving to > > IPv6, nor in the discouragement of IPv4. Making the logging problems > > of running CGNs less severe is, therefore, not going to discourage > > IPv4 nor promote IPv6. Offering advice for how to deploy CGNs does > > not discourage their deployment. > > > > I don't know whether I think the strategy of "Just say no" will work. > > That was, after all, the original answer to doing NAT at all, and it > > didn't work. Certainly the DNS community has been trying to say no > > for years, and that has been a massive failure. But if we're > actually > > going to adopt a "Just say no" strategy, then some of the CGN drafts > > are the sorts of things that will have to be rejected, and I > therefore > > don't think they should become WG items at least until we have > decided > > whether the "No" strategy is a good idea. Otherwise, we'll be > > declaring that we think we should not stop work on the life support > > strategies. > > > > A > > > > -- > > Andrew Sullivan > > ajs@anvilwalrusden.com > > _______________________________________________ > > 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 cathryn@infc.ulst.ac.uk Fri Nov 25 02:08:42 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB26121F8888 for ; Fri, 25 Nov 2011 02:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5zigq669bwD for ; Fri, 25 Nov 2011 02:08:41 -0800 (PST) Received: from e4.ulster.ac.uk (e4.ulster.ac.uk [194.80.87.111]) by ietfa.amsl.com (Postfix) with ESMTP id 44D4521F88B7 for ; Fri, 25 Nov 2011 02:08:41 -0800 (PST) Received: from m0.ulster.ac.uk (m0.ulster.ac.uk [194.80.87.153]) by e4.ulster.ac.uk (UU/BC) with ESMTP id pAPA8cK9012833 for ; Fri, 25 Nov 2011 10:08:38 GMT Received: from martello.infc.ulst.ac.uk (martello.infc.ulst.ac.uk [193.61.166.223]) by m0.ulster.ac.uk (UU/BC) with ESMTP id pAPA8cdv023580 for ; Fri, 25 Nov 2011 10:08:38 GMT (envelope-from cathryn@infc.ulst.ac.uk) Received: from localhost (localhost.localdomain [127.0.0.1]) by martello.infc.ulst.ac.uk (Postfix) with ESMTP id B12153D06DA for ; Fri, 25 Nov 2011 10:08:38 +0000 (GMT) X-Virus-Scanned: amavisd-new at martello.infc.ulst.ac.uk Received: from martello.infc.ulst.ac.uk ([127.0.0.1]) by localhost (martello.infc.ulst.ac.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8rr-OLXt8-V for ; Fri, 25 Nov 2011 10:08:38 +0000 (GMT) Received: from martello.infc.ulst.ac.uk (martello.infc.ulst.ac.uk [193.61.166.223]) by martello.infc.ulst.ac.uk (Postfix) with ESMTP id 7986D3D05BC for ; Fri, 25 Nov 2011 10:08:38 +0000 (GMT) Date: Fri, 25 Nov 2011 10:08:38 +0000 (GMT) From: "Peoples, Cathryn" To: Behave@ietf.org Message-ID: <1539156094.1571322215718391.JavaMail.root@martello.infc.ulst.ac.uk> In-Reply-To: <1021095954.1141322214907854.JavaMail.root@martello.infc.ulst.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [193.61.166.86] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL5_64 (ZimbraWebClient - SAF3 (Win)/5.0.18_GA_3011.RHEL5_64) Subject: [BEHAVE] [CfP] IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) - April 16, 2012 - Hawaii, USA X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 10:08:43 -0000 ----------------------------------------------------------------------------------------------------- Please accept our apologies if you receive multiple copies of this CfP ----------------------------------------------------------------------------------------------------- IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) ================================================================================== 16 April 2012 Maui, Hawaii, USA http://www.manfi.org CALL FOR PAPERS --------------- The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network Operations and Management (CNOM). It is widely agreed that, despite its many successes, the current Internet also has a set of systemic problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack of scalable and agile manageability is arguably more important, as without management, it is impossible to build systems that adapt the services and resources offered in a context-dependent manner. In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future Internet from the beginning. Following the success of the three previous editions of this workshop, held in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this challenging topic. Topics of interest ------------------ Authors are invited to submit papers that fall into or are related to the topic areas listed below: - Architectural Issues * Advantages and disadvantages of revolutionary, evolutionary, and other approaches to managing the Future Internet * Separation of data, control, and management planes * Design of architectural building blocks for managing the Future Internet * Advances in measurement, management, security, accounting, mobility, and other functions * Virtualization of resources and services * Dynamic composition of management and operational functionality * Mechanisms for managing interconnected computational infrastructures (e.g. elastic clouds, federated clouds) in the Future Internet * Implications of social network success on the Future Internet architecture - Design and Implementation Issues * Abstractions for programmable network elements * Accommodating context-awareness in management * Applying situation awareness to network management * Federation between administrative domains and support of all constituencies * The role of models, ontologies, and other knowledge abstractions in the Future Internet * Uncertainty and probabilistic approaches to management of the Future Internet * Approaches for the organization of management data, data analytics and visualization * Experience reports from Future Internet experimental facilities set-up and results - Economic Issues * Economic aspects driving the deployment of Future Internet management technology * Economic opportunities and challenges for management technology * Experience reports from management in test beds Paper submission ---------------- Paper submissions must present original, research or experiences. Late-breaking advances and work-in-progress reports from ongoing research are also encouraged. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 word abstract that clearly outlines the scope and contributions of the paper, and a list of up to 5 key words. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular conference papers, and 4 pages for short papers. Submissions must be in IEEE 2-column style. Papers exceeding these limits, multiple submissions, and self-plagiarized papers will be rejected without further review. Authors should submit their papers in PDF, postscript, or Word formats via JEMS: (https://submissoes.sbc.org.br/). Proceedings ----------- Papers accepted for ManFI 2012 will be included in the conference proceedings, IEEE Xplore, and EI Index. The IEEE reserves the right to remove any paper from IEEE Xplore if the paper is not presented at the workshop. Awards will be presented to the best paper and to the best student paper at the workshop. Furthermore, we plan to work with a leading journal, such as JNSM, TNSM and IJNM, to solicit extended versions of the best papers of ManFI 2012 to be submitted for review. Workshop Co-Chairs ------------------ - Prof. James Won-Ki Hong, POSTECH, Korea - Prof. Filip De Turck, Ghent University - IBBT, Belgium - Dr. Yoshiaki Kiriha, NEC, Japan - Dr. Sven van der Meer, Ericsson LM, Ireland Publicity Co-Chairs ------------------- - Leonidas Lymberopoulos, National Technical University of Athens, Greece - Cathryn Peoples, University of Ulster, UK Important dates --------------- - Abstract registration deadline: December 14, 2011 - Paper submission: December 20, 2011 - Notification of acceptance: January 31, 2012 - Final version of papers due: February 15, 2012 - Workshop date: April 16, 2012 For more information, please contact one of the Workshop Co-Chairs at tpcchairs@manfi2012.org From internet-drafts@ietf.org Wed Nov 30 12:57:39 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B401E1F0C70; Wed, 30 Nov 2011 12:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7sqzZWxtOHk; Wed, 30 Nov 2011 12:57:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E241F0C55; Wed, 30 Nov 2011 12:57:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111130205739.2629.66339.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2011 12:57:39 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 20:57:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Av= oidance Working Group of the IETF. Title : Common requirements for Carrier Grade NATs (CGNs) Author(s) : Simon Perreault Ikuhei Yamagata Shin Miyakawa Akira Nakagawa Hiroyuki Ashida Filename : draft-ietf-behave-lsn-requirements-05.txt Pages : 18 Date : 2011-11-30 This document defines common requirements for Carrier-Grade NAT (CGN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-05.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-05.txt From simon.perreault@viagenie.ca Wed Nov 30 13:00:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FE11F0C77 for ; Wed, 30 Nov 2011 13:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWj8lTq2hSR1 for ; Wed, 30 Nov 2011 13:00:11 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id CECE61F0C74 for ; Wed, 30 Nov 2011 13:00:11 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2E53C21F4E for ; Wed, 30 Nov 2011 15:59:41 -0500 (EST) Message-ID: <4ED6993C.60904@viagenie.ca> Date: Wed, 30 Nov 2011 15:59:40 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: behave@ietf.org References: <20111130205739.2629.66339.idtracker@ietfa.amsl.com> In-Reply-To: <20111130205739.2629.66339.idtracker@ietfa.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-lsn-requirements-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:00:12 -0000 On 2011-11-30 15:57, 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 : Common requirements for Carrier Grade NATs (CGNs) > Author(s) : Simon Perreault > Ikuhei Yamagata > Shin Miyakawa > Akira Nakagawa > Hiroyuki Ashida > Filename : draft-ietf-behave-lsn-requirements-05.txt > Pages : 18 > Date : 2011-11-30 > > This document defines common requirements for Carrier-Grade NAT > (CGN). This revision addresses comments received during WGLC. Here is the change log: o Removed DSCP requirement since it applies to non-CG NATs as well. o Removed instances of "NAT444". o Filtering has no effect on the requirement for a hold down pool. Removed REQ-8-B. o Statically assigned port ranges do not need to go in the hold down pool. Added a new REQ-8-B. o Fixed various nits. More precise text in some places. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca