Shara scope

One approach could be to define here the concept o= f port=20 restricted addresses and sort out the generic problems, and maybe define th= e=20 DHCP extension as one mechanism, and leave the adoption of the concept to o= ther=20 technologies to be done in corresponding working groups.

Best regards,

&n= bsp; Teemu

From: shara-bounces@ietf.org=20 [mailto:shara-bounces@ietf.org] On Behalf Of ext=20 pierre.levis@orange-ftgroup.com
Sent: 26 January, 2009=20 14:45
To: shara@ietf.org
Subject: [shara] Shara=20 scope

Hi,

So, shara deals with "port range" and soft= wire=20 deals with DS-lite, which is fine with me, even if all IPv4 shared addres= s=20 solutions in the same WG would also make sense.

But what about other solutions? I'm thinki= ng of CGN=20 in its Double NAT version. It is a solution already deployed in some ISPs= '=20 networks and the only one currently available on shelves (even if DS-lite= =20 implementations make quick progress).

Shouldn't we integrate a BCP document in t= he=20 "Proposed Work" section to cover this item? Basically considerations of w= here=20 to locate the CGN and how to route the traffic between customers and=20 CGN?

Pierre

--_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E8595A21NOKEUMSG01mgd_-- --===============1733359780== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara --===============1733359780==-- From shara-bounces@ietf.org Tue Jan 27 00:42:51 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86203A6B3A; Tue, 27 Jan 2009 00:42:51 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98E83A6B3A for ; Tue, 27 Jan 2009 00:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmKwwH6QME+l for ; Tue, 27 Jan 2009 00:42:50 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BCEAF3A6B0F for ; Tue, 27 Jan 2009 00:42:49 -0800 (PST) Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LRjWd-0002NU-7Z; Tue, 27 Jan 2009 08:42:30 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 27 Jan 2009 10:42:25 +0200 From: Olaf Maennel To: Message-ID: Thread-Topic: [shara] Shara scope Thread-Index: Acl/s+fQbqY5EJjFQASUaGt+lEYm/wAmWk0wAAN3HX0= In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27E8595A21@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Cc: shara@ietf.org Subject: Re: [shara] Shara scope X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org Hi, Teemu, i completely agree with your definition of the scope. we tried in our draft to separate the functionality of NAT and port-range. ...and i think its possible to cleanly separate those two functions. However, there is an interconnection point. because port-range proposals will need NATs, when connecting legacy devices. As we don't expect that all end-devices will be upgradable (okay, your phones will be - but hosts behind them not necessarily). So there must be some NATing involved somewhere, and actually i believe this could be designed in a really flexible manner. For example in your mobile setting: (1) laptop behind the phone could do it NATing itself (and only send "port-range packets"), (2) the mobile phone could do the NATing, or (3) the base station ??, or (4) the NATing could be done somewhere in the providers network (a la cgn's). All we have to do in port-range is to signal where NATing is possible. Which i believe would be the connection point with behave... Cheers, olaf On 27/01/09 9:23 AM, "teemu.savolainen@nokia.com" wrote: > Hi, > > And behave works with NATs.. I would think NAT, CGN, or multiple instances are > not to be part of this work item as such, as those are already handled > elsewhere? > > What is not done elsewhere is the "port range" and its implications to > protocols, networks, hosts, and applications. > > What could be also discussed to some extent is port restricted IP address > integration to some already existing solutions. For example DHCP-based port > restricted IP address allocation mechanism could be used as DS-Lite extension, > but also as stand-alone feature on point-to-point links. Also other address > assignment methods, like MIP, could be extended with port restricted IP > address allocation support. > > Whatever mechanism to allocate these addresses is used, there are some common > problems like how multiplexing/routing is to be done, blind attacks, protocols > not having ports, fragmentation etc. > > One approach could be to define here the concept of port restricted addresses > and sort out the generic problems, and maybe define the DHCP extension as one > mechanism, and leave the adoption of the concept to other technologies to be > done in corresponding working groups. > > Best regards, > > Teemu > > ________________________________ > From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf Of ext > pierre.levis@orange-ftgroup.com > Sent: 26 January, 2009 14:45 > To: shara@ietf.org > Subject: [shara] Shara scope > > > Hi, > > So, shara deals with "port range" and softwire deals with DS-lite, which is > fine with me, even if all IPv4 shared address solutions in the same WG would > also make sense. > > But what about other solutions? I'm thinking of CGN in its Double NAT version. > It is a solution already deployed in some ISPs' networks and the only one > currently available on shelves (even if DS-lite implementations make quick > progress). > > Shouldn't we integrate a BCP document in the "Proposed Work" section to cover > this item? Basically considerations of where to locate the CGN and how to > route the traffic between customers and CGN? > > > > Pierre > _______________________________________________ > shara mailing list > shara@ietf.org > https://www.ietf.org/mailman/listinfo/shara _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Tue Jan 27 04:45:30 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691AD3A67A5; Tue, 27 Jan 2009 04:45:30 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4A53A67A5 for ; Tue, 27 Jan 2009 04:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMxFt9zHY6Lz for ; Tue, 27 Jan 2009 04:45:29 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EC44A3A6407 for ; Tue, 27 Jan 2009 04:45:28 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EE2752016D for ; Tue, 27 Jan 2009 13:45:09 +0100 (CET) X-AuditID: c1b4fb3e-ab869bb00000429e-9f-497f01d5e432 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D6C532033B for ; Tue, 27 Jan 2009 13:45:09 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 13:44:32 +0100 Received: from [147.214.183.23] ([147.214.183.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 13:44:32 +0100 Message-ID: <497F01B1.9030701@ericsson.com> Date: Tue, 27 Jan 2009 13:44:33 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: shara@ietf.org X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 27 Jan 2009 12:44:32.0944 (UTC) FILETIME=[00CC8300:01C9807D] X-Brightmail-Tracker: AAAAAA== Subject: [shara] Problem statement X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org Hi, I would like to see a better Problem Statement for SHARA. I already gotten questions about the problem statement. I can kind of guess having been involved in the discussion of the related work. But I think there is need for a collected problem statement for SHARA. This also relates to a question that needs to be answered i a good way to enable chartering. Why the problem scope and intended solution proposed? I interpreted Pierre Levis' comments that there clearly are other solutions and what about them. From my perspective as an AD I don't think "let all flowers bloom" is the answer to the IPv4-Ipv6 coexistence and migration issues. We are here to provide recommended solutions within a reasonable time frame so that it actually can impact the market. We don't have forever here, and that is why dual-stack lite was chartered, what appeared to be a reasonable solution and one which we can think IETF can finish documenting this year. So is what SHARA proposes necessary, a sufficient improvement, resolve previously non-handled issues? Should we do it now or focus on first completing the already chartered items in Softwire and Behave? For your knowledge, I need most of these answers quickly. The IESG and IAB have their call to discuss the BOFs next Thursday. By then I need to know as much as possible to have the right discussion about this BOF proposal's approval or not. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Tue Jan 27 05:02:19 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97283A6879; Tue, 27 Jan 2009 05:02:19 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF083A6879 for ; Tue, 27 Jan 2009 05:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fYgaPp59ZF1 for ; Tue, 27 Jan 2009 05:02:18 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEB673A681F for ; Tue, 27 Jan 2009 05:02:17 -0800 (PST) Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LRnZi-000InX-6k; Tue, 27 Jan 2009 13:01:56 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 27 Jan 2009 15:01:52 +0200 From: Olaf Maennel To: Magnus Westerlund Message-ID: Thread-Topic: [shara] Problem statement Thread-Index: AcmAf2wfVuXa7DXEYkmX9i8R71QoaA== In-Reply-To: <497F01B1.9030701@ericsson.com> Mime-version: 1.0 Cc: shara@ietf.org Subject: Re: [shara] Problem statement X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org Hi, = could section 1 and 1.1 from our tech-report (see http://mice.cs.columbia.edu/getTechreport.php?techreportID=3D560) serve as a beginning for this problem statement? or should it better come from a different direction? olaf On 27/01/09 2:44 PM, "Magnus Westerlund" wrote: > Hi, > = > I would like to see a better Problem Statement for SHARA. I already > gotten questions about the problem statement. I can kind of guess having > been involved in the discussion of the related work. But I think there > is need for a collected problem statement for SHARA. > = > This also relates to a question that needs to be answered i a good way > to enable chartering. Why the problem scope and intended solution > proposed? I interpreted Pierre Levis' comments that there clearly are > other solutions and what about them. From my perspective as an AD I > don't think "let all flowers bloom" is the answer to the IPv4-Ipv6 > coexistence and migration issues. We are here to provide recommended > solutions within a reasonable time frame so that it actually can impact > the market. We don't have forever here, and that is why dual-stack lite > was chartered, what appeared to be a reasonable solution and one which > we can think IETF can finish documenting this year. > = > So is what SHARA proposes necessary, a sufficient improvement, resolve > previously non-handled issues? Should we do it now or focus on first > completing the already chartered items in Softwire and Behave? > = > For your knowledge, I need most of these answers quickly. The IESG and > IAB have their call to discuss the BOFs next Thursday. By then I need to > know as much as possible to have the right discussion about this BOF > proposal's approval or not. > = > Cheers > = > Magnus Westerlund > = > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > shara mailing list > shara@ietf.org > https://www.ietf.org/mailman/listinfo/shara _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Tue Jan 27 15:26:17 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86F423A6937; Tue, 27 Jan 2009 15:26:17 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F213A67D9 for ; Tue, 27 Jan 2009 15:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.732 X-Spam-Level: X-Spam-Status: No, score=-6.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY1Jhfkof99j for ; Tue, 27 Jan 2009 15:26:14 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 8B2E93A6937 for ; Tue, 27 Jan 2009 15:26:14 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0RNPc7b007883; Tue, 27 Jan 2009 17:25:52 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 01:25:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 01:25:48 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 28 Jan 2009 00:25:47 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Wed, 28 Jan 2009 00:25:47 +0100 From: To: , Date: Wed, 28 Jan 2009 00:25:46 +0100 Thread-Topic: [shara] Problem statement Thread-Index: AcmAf2wfVuXa7DXEYkmX9i8R71QoaAAUwXkw Message-ID: References: <497F01B1.9030701@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2009 23:25:48.0274 (UTC) FILETIME=[95E1F520:01C980D6] X-Nokia-AV: Clean Cc: shara@ietf.org Subject: Re: [shara] Problem statement X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org Hi Olaf, I think what SHARA should be intended to is: a) develop methods for port-restricted IPv4 address allocation (using dhcp,= ipcp, dsmip, mip4, proxy-mip, whatelse), as a new/additional method for tr= ansition to IPv6 b) develop solutions for the problems a shared IPv4 address creates: fragme= ntation, routing, tunneling, lack of port randomization, etc. c) usage of port restricted IP address to improve network architectures (di= stributed NATs instead of CGNs, etc) The link you sent together with your document (draft-ymbk-aplusp-02.txt) pr= ovide solutions for some of the issues listed in b) and c) above, but that = is part of the solution space instead of the problem statement. If the above points are acceptable, we can work on charter text based those= points and come up with text during this week. - gabor >-----Original Message----- >From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf Of >ext Olaf Maennel >Sent: Tuesday, January 27, 2009 5:02 AM >To: Magnus Westerlund >Cc: shara@ietf.org >Subject: Re: [shara] Problem statement > > >Hi, > >could section 1 and 1.1 from our tech-report (see >http://mice.cs.columbia.edu/getTechreport.php?techreportID=3D560) serve = as >a >beginning for this problem statement? or should it better come from a >different direction? > > olaf > > >On 27/01/09 2:44 PM, "Magnus Westerlund" >wrote: > >> Hi, >> >> I would like to see a better Problem Statement for SHARA. I already >> gotten questions about the problem statement. I can kind of guess >having >> been involved in the discussion of the related work. But I think there >> is need for a collected problem statement for SHARA. >> >> This also relates to a question that needs to be answered i a good way >> to enable chartering. Why the problem scope and intended solution >> proposed? I interpreted Pierre Levis' comments that there clearly are >> other solutions and what about them. From my perspective as an AD I >> don't think "let all flowers bloom" is the answer to the IPv4-Ipv6 >> coexistence and migration issues. We are here to provide recommended >> solutions within a reasonable time frame so that it actually can impact >> the market. We don't have forever here, and that is why dual-stack lite >> was chartered, what appeared to be a reasonable solution and one which >> we can think IETF can finish documenting this year. >> >> So is what SHARA proposes necessary, a sufficient improvement, resolve >> previously non-handled issues? Should we do it now or focus on first >> completing the already chartered items in Softwire and Behave? >> >> For your knowledge, I need most of these answers quickly. The IESG and >> IAB have their call to discuss the BOFs next Thursday. By then I need >to >> know as much as possible to have the right discussion about this BOF >> proposal's approval or not. >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> _______________________________________________ >> shara mailing list >> shara@ietf.org >> https://www.ietf.org/mailman/listinfo/shara > > >_______________________________________________ >shara mailing list >shara@ietf.org >https://www.ietf.org/mailman/listinfo/shara _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Tue Jan 27 15:52:44 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9C63A69EF; Tue, 27 Jan 2009 15:52:44 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BACE3A69EF for ; Tue, 27 Jan 2009 15:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vJ6yl3haL7X for ; Tue, 27 Jan 2009 15:52:42 -0800 (PST) Received: from smtp225.iad.emailsrvr.com (smtp225.iad.emailsrvr.com [207.97.245.225]) by core3.amsl.com (Postfix) with ESMTP id 88FFB3A67EF for ; Tue, 27 Jan 2009 15:52:42 -0800 (PST) Received: from relay12.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay12.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id BCB4020D98E; Tue, 27 Jan 2009 18:52:23 -0500 (EST) Received: by relay12.relay.iad.mlsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id CF71D20D913; Tue, 27 Jan 2009 18:52:22 -0500 (EST) Message-ID: <497F9E35.1080206@isoc.org> Date: Tue, 27 Jan 2009 23:52:21 +0000 From: Matthew Ford User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: Gabor.Bajko@nokia.com References: <497F01B1.9030701@ericsson.com>

In-Reply-To: Cc: shara@ietf.org Subject: Re: [shara] Problem statement X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org Hi all, On 27/1/09 23:25, Gabor.Bajko@nokia.com wrote: > Hi Olaf, > > I think what SHARA should be intended to is: > b) develop solutions for the problems a shared IPv4 address creates: fragmentation, routing, tunneling, lack of port randomization, etc. If there were easy solutions for all the issues created by widespread deployment of shared IPv4 addresses, we wouldn't need IPv6. I think an important work item to add to the charter is documentation of as many of the issues that shared IPv4 addresses create that can be identified by the community at the time. Shared addresses may (or may not) be necessary but they should come with a health warning. I can offer cycles to work on this. Mat _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Tue Jan 27 20:39:59 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8225128C103; Tue, 27 Jan 2009 20:39:59 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4696A3A6BA5 for ; Tue, 27 Jan 2009 20:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xifkjeoASZjI for ; Tue, 27 Jan 2009 20:39:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 63D493A6850 for ; Tue, 27 Jan 2009 20:39:57 -0800 (PST) Received: from [202.214.86.146] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LS2DA-000HxY-Cy; Wed, 28 Jan 2009 04:39:36 +0000 Message-ID: <497FE17E.7030207@psg.com> Date: Wed, 28 Jan 2009 13:39:26 +0900 From: Randy Bush User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: Gabor.Bajko@nokia.com References: <497F01B1.9030701@ericsson.com>

In-Reply-To: Cc: shara@ietf.org Subject: Re: [shara] Problem statement X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org > a) develop methods for port-restricted IPv4 address allocation (using > dhcp, ipcp, dsmip, mip4, proxy-mip, whatelse), as a new/additional > method for transition to IPv6 > > b) develop solutions for the problems a shared IPv4 address creates: > fragmentation, routing, tunneling, lack of port randomization, etc. > > c) usage of port restricted IP address to improve network > architectures (distributed NATs instead of CGNs, etc) i like "address sharing" as opposed to specifying using port number. there are a few folk thinking of stealing bits from the ip frag ident number instead. i am neither advocating nor dissing this idea. just trying to leave room for it. randy _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Tue Jan 27 20:40:51 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6AD03A6BA5; Tue, 27 Jan 2009 20:40:51 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFA228C155 for ; Tue, 27 Jan 2009 20:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.079 X-Spam-Level: X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aad03BZWrXwG for ; Tue, 27 Jan 2009 20:40:49 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 908B73A6850 for ; Tue, 27 Jan 2009 20:40:49 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0S4d4CA021532 for ; Tue, 27 Jan 2009 22:40:27 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 06:39:43 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 06:39:43 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 06:39:38 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 28 Jan 2009 05:39:37 +0100 From: To: Date: Wed, 28 Jan 2009 05:39:32 +0100 Thread-Topic: [shara] Problem statement Thread-Index: AcmA2lE3maEIELPaS0mG40N3HYpfHAAJ0kvQ Message-ID: References: <497F01B1.9030701@ericsson.com>

<497F9E35.1080206@isoc.org> In-Reply-To: <497F9E35.1080206@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jan 2009 04:39:38.0032 (UTC) FILETIME=[6D4B0300:01C98102] X-Nokia-AV: Clean Subject: Re: [shara] Problem statement X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org >-----Original Message----- >From: ext Matthew Ford [mailto:ford@isoc.org] >Sent: Tuesday, January 27, 2009 3:52 PM >To: Bajko Gabor (Nokia-CIC/MtView) >Cc: omaennel@net.t-labs.tu-berlin.de; magnus.westerlund@ericsson.com; >shara@ietf.org >Subject: Re: [shara] Problem statement > >Hi all, > >On 27/1/09 23:25, Gabor.Bajko@nokia.com wrote: >> Hi Olaf, >> >> I think what SHARA should be intended to is: > >> b) develop solutions for the problems a shared IPv4 address creates: >fragmentation, routing, tunneling, lack of port randomization, etc. > >If there were easy solutions for all the issues created by widespread >deployment of shared IPv4 addresses, we wouldn't need IPv6. > >I think an important work item to add to the charter is documentation of >as many of the issues that shared IPv4 addresses create that can be >identified by the community at the time. Shared addresses may (or may >not) be necessary but they should come with a health warning. Good point to add. The intention is to emphasize that this solution is a temporary one to be used during the transition period, and not an alternative to IPv6 (not even on the short term). >I can offer cycles to work on this. Thanks, your input is needed and appreciated. - gabor >Mat _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Wed Jan 28 04:54:43 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A78228C25E; Wed, 28 Jan 2009 04:54:43 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091C728C1D2 for ; Wed, 28 Jan 2009 04:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3grvXRj2kiE for ; Wed, 28 Jan 2009 04:54:42 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id CC01D28C25E for ; Wed, 28 Jan 2009 04:54:41 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 13:54:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Jan 2009 13:54:21 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [shara] Problem statement thread-index: AcmA2lE3maEIELPaS0mG40N3HYpfHAAJ0kvQABFPZIA= From: To: , X-OriginalArrivalTime: 28 Jan 2009 12:54:21.0207 (UTC) FILETIME=[89D81270:01C98147] Cc: Gabor.Bajko@nokia.com Subject: Re: [shara] Problem statement X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org Hi, I've just submitted the following draft that could be valuable information = for shara chartering: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv4 Shortage Framework Author(s) : P. Levis, et al. Filename : draft-levis-behave-ipv4-shortage-framework-00.txt Pages : 15 Date : 2009-01-28 This document analyses the main issues related to IPv4 Internet access in the context of public IPv4 address exhaustion. It would be valuable to assess each IPv4 address shortage solution with all these issues, to check to what degree they are concerned, how they handle each issue, and to what extent they resolve the pending problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levis-behave-ipv4-shortage-framew= ork-00.txt > -----Message d'origine----- > De : shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] = > De la part de Gabor.Bajko@nokia.com > Envoy=E9 : mercredi 28 janvier 2009 05:40 > =C0 : shara@ietf.org > Objet : Re: [shara] Problem statement > = > = > = > >-----Original Message----- > >From: ext Matthew Ford [mailto:ford@isoc.org] > >Sent: Tuesday, January 27, 2009 3:52 PM > >To: Bajko Gabor (Nokia-CIC/MtView) > >Cc: omaennel@net.t-labs.tu-berlin.de; = > magnus.westerlund@ericsson.com; > >shara@ietf.org > >Subject: Re: [shara] Problem statement > > > >Hi all, > > > >On 27/1/09 23:25, Gabor.Bajko@nokia.com wrote: > >> Hi Olaf, > >> > >> I think what SHARA should be intended to is: > > > >> b) develop solutions for the problems a shared IPv4 = > address creates: > >fragmentation, routing, tunneling, lack of port randomization, etc. > > > >If there were easy solutions for all the issues created by = > widespread > >deployment of shared IPv4 addresses, we wouldn't need IPv6. > > > >I think an important work item to add to the charter is = > documentation of > >as many of the issues that shared IPv4 addresses create that can be > >identified by the community at the time. Shared addresses = > may (or may > >not) be necessary but they should come with a health warning. > = > Good point to add. The intention is to emphasize that this = > solution is a temporary one to be used during the transition = > period, and not an alternative to IPv6 (not even on the short term). > = > >I can offer cycles to work on this. > = > Thanks, your input is needed and appreciated. > - gabor > = > >Mat > _______________________________________________ > shara mailing list > shara@ietf.org > https://www.ietf.org/mailman/listinfo/shara > = _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Wed Jan 28 12:04:26 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9459328C12C; Wed, 28 Jan 2009 12:04:26 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A05B28C130 for ; Wed, 28 Jan 2009 12:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+vOf0PPbDeG for ; Wed, 28 Jan 2009 12:04:24 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 5126E28C12C for ; Wed, 28 Jan 2009 12:04:24 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0SK3s7D011276; Wed, 28 Jan 2009 14:04:02 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 22:04:02 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 22:04:01 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 22:03:56 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 28 Jan 2009 21:03:55 +0100 From: To: Date: Wed, 28 Jan 2009 21:03:31 +0100 Thread-Topic: [shara] Shara scope Thread-Index: Acl/s+fQbqY5EJjFQASUaGt+lEYm/wAmWk0wAAN3HX0ASZBrsA== Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E85E1E9D@NOK-EUMSG-01.mgdnok.nokia.com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F27E8595A21@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jan 2009 20:03:56.0388 (UTC) FILETIME=[8D0C9240:01C98183] X-Nokia-AV: Clean Cc: shara@ietf.org Subject: Re: [shara] Shara scope X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org Hi, I ment that there's no need to work here about how NATs work (or how those are traversed) in general, but indeed the coexistence with NATs and placement of NAT are of interest. While new phones could be containing support for this feature, the old ones definitely would not. Thus the gateway serving large number of terminals would need to provide public IPv4 address or NAT for some while letting others use shared addresses. And this distribution would likely change as legacy devices would go away and new ones come in, and even more so when IPv6 becomes common. About the signaling. On the DHCP-based solutions, I think (at least in our proposal solution) the signaling could work by node sending in DHCPDISCOVER indication of its support for shared addresses, and with that it would implicitly indicate no need for NATting by the delegating host (if it indeed delegates shared addresses). On the chain of delegating nodes the first node that does not indicate support for shared addresses in its DHCPDISCOVER essentially indicates to the node above to provide private IPv4 address and instantiate NAT. Best regards, Teemu >-----Original Message----- >From: ext Olaf Maennel [mailto:omaennel@net.t-labs.tu-berlin.de] >Sent: 27 January, 2009 10:42 >To: Savolainen Teemu (Nokia-D-MSW/Tampere) >Cc: shara@ietf.org >Subject: Re: [shara] Shara scope > > >Hi, > >Teemu, i completely agree with your definition of the scope. >we tried in our draft to separate the functionality of NAT and >port-range. ...and i think its possible to cleanly separate >those two functions. > >However, there is an interconnection point. because port-range >proposals will need NATs, when connecting legacy devices. As >we don't expect that all end-devices will be upgradable (okay, >your phones will be - but hosts behind them not necessarily). >So there must be some NATing involved somewhere, and actually >i believe this could be designed in a really flexible manner. >For example in your mobile setting: (1) laptop behind the >phone could do it NATing itself (and only send "port-range >packets"), (2) the mobile phone could do the NATing, or (3) >the base station ??, or (4) the NATing could be done somewhere >in the providers network (a la cgn's). >All we have to do in port-range is to signal where NATing is >possible. Which i believe would be the connection point with behave... > >Cheers, > > olaf > > >On 27/01/09 9:23 AM, "teemu.savolainen@nokia.com" > wrote: >> Hi, >> >> And behave works with NATs.. I would think NAT, CGN, or multiple >> instances are not to be part of this work item as such, as those are >> already handled elsewhere? >> >> What is not done elsewhere is the "port range" and its >implications to >> protocols, networks, hosts, and applications. >> >> What could be also discussed to some extent is port restricted IP >> address integration to some already existing solutions. For example >> DHCP-based port restricted IP address allocation mechanism could be >> used as DS-Lite extension, but also as stand-alone feature on >> point-to-point links. Also other address assignment methods, >like MIP, >> could be extended with port restricted IP address allocation support. >> >> Whatever mechanism to allocate these addresses is used, >there are some >> common problems like how multiplexing/routing is to be done, blind >> attacks, protocols not having ports, fragmentation etc. >> >> One approach could be to define here the concept of port restricted >> addresses and sort out the generic problems, and maybe >define the DHCP >> extension as one mechanism, and leave the adoption of the concept to >> other technologies to be done in corresponding working groups. >> >> Best regards, >> >> Teemu >> >> ________________________________ >> From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] >On Behalf >> Of ext pierre.levis@orange-ftgroup.com >> Sent: 26 January, 2009 14:45 >> To: shara@ietf.org >> Subject: [shara] Shara scope >> >> >> Hi, >> >> So, shara deals with "port range" and softwire deals with DS-lite, >> which is fine with me, even if all IPv4 shared address solutions in >> the same WG would also make sense. >> >> But what about other solutions? I'm thinking of CGN in its >Double NAT version. >> It is a solution already deployed in some ISPs' networks and >the only >> one currently available on shelves (even if DS-lite implementations >> make quick progress). >> >> Shouldn't we integrate a BCP document in the "Proposed Work" section >> to cover this item? Basically considerations of where to locate the >> CGN and how to route the traffic between customers and CGN? >> >> >> >> Pierre >> _______________________________________________ >> shara mailing list >> shara@ietf.org >> https://www.ietf.org/mailman/listinfo/shara > > > _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Wed Jan 28 14:39:29 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4F328C1AD; Wed, 28 Jan 2009 14:39:29 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C15528C1AD for ; Wed, 28 Jan 2009 14:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si-BVMnxZJbA for ; Wed, 28 Jan 2009 14:39:27 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 396F228C17E for ; Wed, 28 Jan 2009 14:39:26 -0800 (PST) Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LSJ3n-000Gw4-Do; Wed, 28 Jan 2009 22:39:06 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 29 Jan 2009 00:38:58 +0200 From: Olaf Maennel To: Message-ID: Thread-Topic: [shara] Shara scope Thread-Index: Acl/s+fQbqY5EJjFQASUaGt+lEYm/wAmWk0wAAN3HX0ASZBrsAAF8YZl In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27E85E1E9D@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Cc: shara@ietf.org Subject: Re: [shara] Shara scope X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org Hi, On 28/01/09 10:03 PM, "teemu.savolainen@nokia.com" wrote: > Hi, > > I ment that there's no need to work here about how NATs work (or how those are > traversed) in general, but indeed the coexistence with NATs and placement of > NAT are of interest. > > While new phones could be containing support for this feature, the old ones > definitely would not. Thus the gateway serving large number of terminals would > need to provide public IPv4 address or NAT for some while letting others use > shared addresses. And this distribution would likely change as legacy devices > would go away and new ones come in, and even more so when IPv6 becomes common. if i recall correctly, Alain said something very similar... just he wasn't talking about phones. :) > About the signaling. On the DHCP-based solutions, I think (at least in our > proposal solution) the signaling could work by node sending in DHCPDISCOVER > indication of its support for shared addresses, and with that it would > implicitly indicate no need for NATting by the delegating host (if it indeed > delegates shared addresses). just an initial list of bullet-points what needs to be signaled. (I think its identical with what you said...): - a set of public IPv4 addresses, - for each IPv4 address the allocated port-range, - the tunneling technology to be used (e.g., "in-IPv6-encapsulation", or in your case that you have layer-2) - addresses of the tunnel endpoints (e.g., IPv6 address of tunnel endpoints) - whether or not NAT functionality is provided by the gateway anything missing besides a version number and some reserved bits for future use? :) > On the chain of delegating nodes the first node > that does not indicate support for shared addresses in its DHCPDISCOVER > essentially indicates to the node above to provide private IPv4 address and > instantiate NAT. agreed. olaf _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Thu Jan 29 07:27:52 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651B93A6874; Thu, 29 Jan 2009 07:27:52 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69293A6874 for ; Thu, 29 Jan 2009 07:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eignNQK2PO8 for ; Thu, 29 Jan 2009 07:27:49 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 100113A6843 for ; Thu, 29 Jan 2009 07:27:48 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0TFR68x019359 for ; Thu, 29 Jan 2009 17:27:28 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jan 2009 17:27:12 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jan 2009 17:27:07 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jan 2009 17:26:57 +0200 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 29 Jan 2009 16:26:57 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Thu, 29 Jan 2009 16:26:56 +0100 From: To: Date: Thu, 29 Jan 2009 16:26:33 +0100 Thread-Topic: Updated BOF proposal Thread-Index: AcmCJfd/CeMCYFBTQfGM26gvfC7PRQ== Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E8617AEF@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jan 2009 15:26:57.0582 (UTC) FILETIME=[05E1C4E0:01C98226] X-Nokia-AV: Clean Subject: [shara] Updated BOF proposal X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org Hi, I updated the BOF proposal (http://trac.tools.ietf.org/bof/trac/wiki/SHARABOF). All comments, including text suggestions, are welcome: -- Sharing of an IPv4 Address (shara) BOF -------------------------------------- Agenda draft: ------------- 1. Introduction, Agenda, Blue sheets, BoF Organizers, 5 minutes 2. Overall Scope and Problem Description: TBD, 15 minutes 3. Detailed Problem Descriptions: TBD, Max 40 minutes 3.1. Routing and tunneling 3.2. Preventing blind attacks 3.3. Protocols that do not utilize ports (ICMP, 6to4, ...) 3.4. Fragmentation 3.5. Protocols embedding IPv4 addresses 3.6. Applications assuming uniqueness of IPv4 address / that do not allow simultaneous usage of a resource multiple times from the same IPv4 address 3.7. Server applications on shared-address hosts 3.8. Support for multicast 3.9. Integrating with other existing transition methods (e.g. DS-Lite) 4. Overview of solution proposals on table, TBD, 20 minutes 5. BoF Proposal Discussion, All, 20 minutes 6. Decision on proceeding to WG chartering discussion or on turning BOF into non WG-forming BOF 7. Charter discussion, All, 20 minutes 8. Summary, Next steps : TBD, 10 minutes Reading List (to be updated as new draft (revisions) are submitted): * http://tools.ietf.org/internet-drafts/draft-levis-behave-ipv4-shortage-framework * http://tools.ietf.org/html/draft-ymbk-aplusp * http://tools.ietf.org/html/draft-boucadair-port-range * http://tools.ietf.org/html/draft-bajko-v6ops-port-restricted-ipaddr-assign * http://tools.ietf.org/html/draft-boucadair-dhc-port-range * http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange * http://tools.ietf.org/html/draft-arkko-townsley-coexistence * http://tools.ietf.org/html/draft-despres-sam Background and Motivation: -------------------------- As the IPv4 exhaustion draws nearer and happens, it will not be always possible to allocate hosts with public IPv4 addresses. While IPv6 is the long-term solution, IPv4 connectivity needs to be provided for hosts and applications unable to utilize IPv6 and/or require NATless IPv4 connectivity. This can happen for example when: * a host is provided with IPv6 only connectivity by access network, but it is running (legacy) applications requiring NATless IPv4 connectivity * a distribution of NAT to edges instead of core is desired e.g. for better end-user control of NAT or for distribution of NAT function In IETF multiple IPv6 transition solutions have been and are being worked on, including protocol translation that is worked on behave WG and Dual-Stack Lite that is worked on softwire WG. This BOF proposes new work on: * defining complementing, _not competing_, model for shared IPv4 addresses * documenting the deployment scenarios where usage of such addresses is envisioned and beneficial over other solutions being standardized * defining protocol for assigning and routing shared IPv4 addresses. * documentation of the benefits, dangers, and drawbacks of shared IPv4 addresses As the IPv4 address exhaustion is already close, the working group shall develop these solutions during 2010. Prior Activity: ---------------- IPv6 transition mechanisms have a long history. Port-restricted IPv4 addresses as a solution approach have been discussed during 2008 at least in IETF#72, IETF#73, and to lesser extent in v4v6 interim meeting held in Montreal: IETF#73 * Softwires WG: https://www.ietf.org/proceedings/08nov/index.html * Behave WG: https://www.ietf.org/proceedings/08nov/index.html IPv4-IPv6 Co-Existence Interim * http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim IETF#72 * intarea: https://www.ietf.org/proceedings/08jul/index.html * v6ops: https://www.ietf.org/proceedings/08jul/index.html Proposed Work: -------------- The proposed shara working group will focus on following topics relevant for port restricted IPv4 addresses: * Problem statement and requirement document: a document describing the problem why shared IPv4 addresses are needed, what requirements solutions need to fulfill, and what issues can arise from introduction of the shared address concept * Deployment scenarios: a document describing deployment scenarios where shared IPv4 addresses are applicable (e.g. integration with Dual-Stack Lite, point-to-point physical links, distributing Carrier Grade NAT, IP mobility protocols etc), describing and providing solutions to the problems it creates (e.g. port spoofing, ICMP handling, fragmentation, routing, tunneling, etc) * Shared address assignment: a document describing mechanisms for assigning shared IPv4 addresses for hosts Approximate Timeline for Deliverables: -------------------------------------- * April 2009 WG approved by IESG * 2H09 Submit problem statement I-D to IESG * 1H10 Submit address assignment I-D to IESG * 2H10 Submit deployment scenarios I-D to IESG * 2H10 Recharter or close WG -- Best regards, Teemu _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Thu Jan 29 22:23:28 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC7A3A698A; Thu, 29 Jan 2009 22:23:28 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A23F3A698A for ; Thu, 29 Jan 2009 22:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0uxj8EVcGsU for ; Thu, 29 Jan 2009 22:23:26 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id D2F1D3A688F for ; Thu, 29 Jan 2009 22:23:25 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jan 2009 07:23:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Jan 2009 07:23:05 +0100 Message-ID: In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27E8617AEF@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [shara] Updated BOF proposal thread-index: AcmCJfd/CeMCYFBTQfGM26gvfC7PRQAeecDA From: To: , X-OriginalArrivalTime: 30 Jan 2009 06:23:06.0054 (UTC) FILETIME=[36637E60:01C982A3] Subject: Re: [shara] Updated BOF proposal X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org Thank you Teemu for this update, I guess we still need to precise a bit more the scope of shara. "Sharing of an IPv4 Address" is the very generic target for all solutions t= hat deal with IPv4 access, using IPv4, in the context of IPv4 public addres= s exhaustion. = So, it encompasses both CGN solutions (including: DS-lite, Double NAT, and = other flavors that I guess are around and soon to be released -I'm not invo= lved in them!-, ...) and "port range" solutions (the reading list you menti= on), as well as some more exotic approach as the ident bits use, pointed ou= t by Randy. So, there are two extreme possible positions: 1) We only deal with "port range" solutions 2) We deal with all solutions but DS-lite (which is for softwire) I think we must but very clear and explicit on this matter. Regards Pierre > -----Message d'origine----- > De : shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] = > De la part de teemu.savolainen@nokia.com > Envoy=E9 : jeudi 29 janvier 2009 16:27 > =C0 : shara@ietf.org > Objet : [shara] Updated BOF proposal > = > Hi, > = > I updated the BOF proposal = > (http://trac.tools.ietf.org/bof/trac/wiki/SHARABOF). All = > comments, including text suggestions, are welcome: > -- > Sharing of an IPv4 Address (shara) BOF > -------------------------------------- > = > Agenda draft: > ------------- > = > 1. Introduction, Agenda, Blue sheets, BoF Organizers, 5 minutes > = > 2. Overall Scope and Problem Description: TBD, 15 minutes > = > 3. Detailed Problem Descriptions: TBD, Max 40 minutes > = > 3.1. Routing and tunneling > = > 3.2. Preventing blind attacks > = > 3.3. Protocols that do not utilize ports (ICMP, 6to4, ...) > = > 3.4. Fragmentation > = > 3.5. Protocols embedding IPv4 addresses > = > 3.6. Applications assuming uniqueness of IPv4 address / = > that do not allow simultaneous usage of a resource multiple = > times from the same IPv4 address > = > 3.7. Server applications on shared-address hosts > = > 3.8. Support for multicast > = > 3.9. Integrating with other existing transition methods = > (e.g. DS-Lite) > = > 4. Overview of solution proposals on table, TBD, 20 minutes > = > 5. BoF Proposal Discussion, All, 20 minutes > = > 6. Decision on proceeding to WG chartering discussion or on = > turning BOF into non WG-forming BOF > = > 7. Charter discussion, All, 20 minutes > = > 8. Summary, Next steps : TBD, 10 minutes > = > Reading List (to be updated as new draft (revisions) are submitted): > = > * = > http://tools.ietf.org/internet-drafts/draft-levis-behave-ipv4- > shortage-framework > * http://tools.ietf.org/html/draft-ymbk-aplusp > * http://tools.ietf.org/html/draft-boucadair-port-range > * = > http://tools.ietf.org/html/draft-bajko-v6ops-port-restricted-i > paddr-assign > * http://tools.ietf.org/html/draft-boucadair-dhc-port-range > * = > http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange > * http://tools.ietf.org/html/draft-arkko-townsley-coexistence > * http://tools.ietf.org/html/draft-despres-sam > = > = > Background and Motivation: > -------------------------- > = > As the IPv4 exhaustion draws nearer and happens, it will not = > be always possible to allocate hosts with public IPv4 addresses. > = > While IPv6 is the long-term solution, IPv4 connectivity needs = > to be provided for hosts and applications unable to utilize = > IPv6 and/or require NATless IPv4 connectivity. This can = > happen for example when: > = > * a host is provided with IPv6 only connectivity by = > access network, but it is running (legacy) applications = > requiring NATless IPv4 connectivity > * a distribution of NAT to edges instead of core is = > desired e.g. for better end-user control of NAT or for = > distribution of NAT function > = > In IETF multiple IPv6 transition solutions have been and are = > being worked on, including protocol translation that is = > worked on behave WG and Dual-Stack Lite that is worked on = > softwire WG. This BOF proposes new work on: > = > * defining complementing, _not competing_, model for = > shared IPv4 addresses > * documenting the deployment scenarios where usage of = > such addresses is envisioned and beneficial over other = > solutions being standardized > * defining protocol for assigning and routing shared IPv4 = > addresses. > * documentation of the benefits, dangers, and drawbacks = > of shared IPv4 addresses > = > As the IPv4 address exhaustion is already close, the working = > group shall develop these solutions during 2010. > = > Prior Activity: > ---------------- > = > IPv6 transition mechanisms have a long history. = > Port-restricted IPv4 addresses as a solution approach have = > been discussed during 2008 at least in IETF#72, IETF#73, and = > to lesser extent in v4v6 interim meeting held in Montreal: > = > IETF#73 > = > * Softwires WG: https://www.ietf.org/proceedings/08nov/index.html > * Behave WG: https://www.ietf.org/proceedings/08nov/index.html > = > IPv4-IPv6 Co-Existence Interim > = > * http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim > = > IETF#72 > = > * intarea: https://www.ietf.org/proceedings/08jul/index.html > * v6ops: https://www.ietf.org/proceedings/08jul/index.html > = > Proposed Work: > -------------- > = > The proposed shara working group will focus on following = > topics relevant for port restricted IPv4 addresses: > = > * Problem statement and requirement document: a document = > describing the problem why shared IPv4 addresses are needed, = > what requirements solutions need to fulfill, and what issues = > can arise from introduction of the shared address concept > = > * Deployment scenarios: a document describing deployment = > scenarios where shared IPv4 addresses are applicable (e.g. = > integration with Dual-Stack Lite, point-to-point physical = > links, distributing Carrier Grade NAT, IP mobility protocols = > etc), describing and providing solutions to the problems it = > creates (e.g. port spoofing, ICMP handling, fragmentation, = > routing, tunneling, etc) > = > * Shared address assignment: a document describing = > mechanisms for assigning shared IPv4 addresses for hosts > = > Approximate Timeline for Deliverables: > -------------------------------------- > = > * April 2009 WG approved by IESG > * 2H09 Submit problem statement I-D to IESG > * 1H10 Submit address assignment I-D to IESG > * 2H10 Submit deployment scenarios I-D to IESG > * 2H10 Recharter or close WG > = > -- > = > Best regards, > = > Teemu > = > _______________________________________________ > shara mailing list > shara@ietf.org > https://www.ietf.org/mailman/listinfo/shara > = _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Fri Jan 30 00:27:45 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDE93A68C6; Fri, 30 Jan 2009 00:27:45 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4569E3A6800 for ; Fri, 30 Jan 2009 00:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2gb7jhWwF19 for ; Fri, 30 Jan 2009 00:27:43 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 943963A6A14 for ; Fri, 30 Jan 2009 00:27:42 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0U8RHQf013993; Fri, 30 Jan 2009 10:27:21 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jan 2009 10:26:50 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jan 2009 10:26:50 +0200 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 30 Jan 2009 09:26:49 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Fri, 30 Jan 2009 09:26:49 +0100 From: To: , Date: Fri, 30 Jan 2009 09:26:49 +0100 Thread-Topic: [shara] Updated BOF proposal Thread-Index: AcmCJfd/CeMCYFBTQfGM26gvfC7PRQAeecDAAAUoFvU= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2009 08:26:50.0535 (UTC) FILETIME=[7FB96370:01C982B4] X-Nokia-AV: Clean Subject: Re: [shara] Updated BOF proposal X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org Hi, IMHO there's third: we look at solution proposals currently not worked on e= lsewhere and during WG work pick the one that fulfills the agreed requireme= nts best (including requirements of timing and complementing of existing so= lutions). That is why this is currently openly scoped. Personally, I can agree on focusing this BOF to just "port ranges" and then= discuss on details of how that is accomplished (e.g. With DHCP). But I pre= fer having rough consensus on the scope instead of just pushing for what I = myself prefer. I'd love to see opinions from still more people reading this list. Best regards, Teemu --- original message --- From: "ext pierre.levis@orange-ftgroup.com" Subject: RE: [shara] Updated BOF proposal Date: 30th January 2009 Time: 8:23:17 am Thank you Teemu for this update, I guess we still need to precise a bit more the scope of shara. "Sharing of an IPv4 Address" is the very generic target for all solutions t= hat deal with IPv4 access, using IPv4, in the context of IPv4 public addres= s exhaustion. So, it encompasses both CGN solutions (including: DS-lite, Double NAT, and = other flavors that I guess are around and soon to be released -I'm not invo= lved in them!-, ...) and "port range" solutions (the reading list you menti= on), as well as some more exotic approach as the ident bits use, pointed ou= t by Randy. So, there are two extreme possible positions: 1) We only deal with "port range" solutions 2) We deal with all solutions but DS-lite (which is for softwire) I think we must but very clear and explicit on this matter. Regards Pierre > -----Message d'origine----- > De : shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] > De la part de teemu.savolainen@nokia.com > Envoy=E9 : jeudi 29 janvier 2009 16:27 > =C0 : shara@ietf.org > Objet : [shara] Updated BOF proposal > > Hi, > > I updated the BOF proposal > (http://trac.tools.ietf.org/bof/trac/wiki/SHARABOF). All > comments, including text suggestions, are welcome: > -- > Sharing of an IPv4 Address (shara) BOF > -------------------------------------- > > Agenda draft: > ------------- > > 1. Introduction, Agenda, Blue sheets, BoF Organizers, 5 minutes > > 2. Overall Scope and Problem Description: TBD, 15 minutes > > 3. Detailed Problem Descriptions: TBD, Max 40 minutes > > 3.1. Routing and tunneling > > 3.2. Preventing blind attacks > > 3.3. Protocols that do not utilize ports (ICMP, 6to4, ...) > > 3.4. Fragmentation > > 3.5. Protocols embedding IPv4 addresses > > 3.6. Applications assuming uniqueness of IPv4 address / > that do not allow simultaneous usage of a resource multiple > times from the same IPv4 address > > 3.7. Server applications on shared-address hosts > > 3.8. Support for multicast > > 3.9. Integrating with other existing transition methods > (e.g. DS-Lite) > > 4. Overview of solution proposals on table, TBD, 20 minutes > > 5. BoF Proposal Discussion, All, 20 minutes > > 6. Decision on proceeding to WG chartering discussion or on > turning BOF into non WG-forming BOF > > 7. Charter discussion, All, 20 minutes > > 8. Summary, Next steps : TBD, 10 minutes > > Reading List (to be updated as new draft (revisions) are submitted): > > * > http://tools.ietf.org/internet-drafts/draft-levis-behave-ipv4- > shortage-framework > * http://tools.ietf.org/html/draft-ymbk-aplusp > * http://tools.ietf.org/html/draft-boucadair-port-range > * > http://tools.ietf.org/html/draft-bajko-v6ops-port-restricted-i > paddr-assign > * http://tools.ietf.org/html/draft-boucadair-dhc-port-range > * > http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange > * http://tools.ietf.org/html/draft-arkko-townsley-coexistence > * http://tools.ietf.org/html/draft-despres-sam > > > Background and Motivation: > -------------------------- > > As the IPv4 exhaustion draws nearer and happens, it will not > be always possible to allocate hosts with public IPv4 addresses. > > While IPv6 is the long-term solution, IPv4 connectivity needs > to be provided for hosts and applications unable to utilize > IPv6 and/or require NATless IPv4 connectivity. This can > happen for example when: > > * a host is provided with IPv6 only connectivity by > access network, but it is running (legacy) applications > requiring NATless IPv4 connectivity > * a distribution of NAT to edges instead of core is > desired e.g. for better end-user control of NAT or for > distribution of NAT function > > In IETF multiple IPv6 transition solutions have been and are > being worked on, including protocol translation that is > worked on behave WG and Dual-Stack Lite that is worked on > softwire WG. This BOF proposes new work on: > > * defining complementing, _not competing_, model for > shared IPv4 addresses > * documenting the deployment scenarios where usage of > such addresses is envisioned and beneficial over other > solutions being standardized > * defining protocol for assigning and routing shared IPv4 > addresses. > * documentation of the benefits, dangers, and drawbacks > of shared IPv4 addresses > > As the IPv4 address exhaustion is already close, the working > group shall develop these solutions during 2010. > > Prior Activity: > ---------------- > > IPv6 transition mechanisms have a long history. > Port-restricted IPv4 addresses as a solution approach have > been discussed during 2008 at least in IETF#72, IETF#73, and > to lesser extent in v4v6 interim meeting held in Montreal: > > IETF#73 > > * Softwires WG: https://www.ietf.org/proceedings/08nov/index.html > * Behave WG: https://www.ietf.org/proceedings/08nov/index.html > > IPv4-IPv6 Co-Existence Interim > > * http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim > > IETF#72 > > * intarea: https://www.ietf.org/proceedings/08jul/index.html > * v6ops: https://www.ietf.org/proceedings/08jul/index.html > > Proposed Work: > -------------- > > The proposed shara working group will focus on following > topics relevant for port restricted IPv4 addresses: > > * Problem statement and requirement document: a document > describing the problem why shared IPv4 addresses are needed, > what requirements solutions need to fulfill, and what issues > can arise from introduction of the shared address concept > > * Deployment scenarios: a document describing deployment > scenarios where shared IPv4 addresses are applicable (e.g. > integration with Dual-Stack Lite, point-to-point physical > links, distributing Carrier Grade NAT, IP mobility protocols > etc), describing and providing solutions to the problems it > creates (e.g. port spoofing, ICMP handling, fragmentation, > routing, tunneling, etc) > > * Shared address assignment: a document describing > mechanisms for assigning shared IPv4 addresses for hosts > > Approximate Timeline for Deliverables: > -------------------------------------- > > * April 2009 WG approved by IESG > * 2H09 Submit problem statement I-D to IESG > * 1H10 Submit address assignment I-D to IESG > * 2H10 Submit deployment scenarios I-D to IESG > * 2H10 Recharter or close WG > > -- > > Best regards, > > Teemu > > _______________________________________________ > shara mailing list > shara@ietf.org > https://www.ietf.org/mailman/listinfo/shara > _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Fri Jan 30 02:17:12 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1234C3A6A9B; Fri, 30 Jan 2009 02:17:12 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3A03A6A9B for ; Fri, 30 Jan 2009 02:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.022 X-Spam-Level: X-Spam-Status: No, score=-3.022 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z69dugEUgSrA for ; Fri, 30 Jan 2009 02:17:10 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 363C13A6840 for ; Fri, 30 Jan 2009 02:17:10 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jan 2009 11:16:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C982C3.DCA67318" Date: Fri, 30 Jan 2009 11:16:48 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-boucadair-port-range-01.txt thread-index: AcmCvXIHWTn+rYi4RyezeLo5r/+i1AABjYkw From: To: X-OriginalArrivalTime: 30 Jan 2009 10:16:48.0892 (UTC) FILETIME=[DCA6C3C0:01C982C3] Subject: [shara] TR: I-D Action:draft-boucadair-port-range-01.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C982C3.DCA67318 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to draw your attention on the following draft which is an = enhanced version based on the two following drafts previously submitted:

Looking forward to reading your comments. Regards Pierre -----Message d'origine----- De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = Internet-Drafts@ietf.org Envoy=E9 : vendredi 30 janvier 2009 10:30 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-port-range-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : IPv4 Connectivity Access in the Context of IPv4 = Address Exhaustion Author(s) : M. Boucadair, et al. Filename : draft-boucadair-port-range-01.txt Pages : 41 Date : 2009-01-30 This memo proposes a solution, based on fractional addresses, to face the IPv4 public address exhaustion. It details the solution and presents a mock-up implementation, with the results of tests that validate the concept. It also describes architectures and how fractional addresses are used to overcome the IPv4 address shortage. A comparison with the alternative Carrier-Grade NAT (CG-NAT) solutions is also elaborated in the document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-port-range-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C982C3.DCA67318 Content-Type: application/octet-stream; name="draft-boucadair-port-range-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-boucadair-port-range-01.URL Content-Disposition: attachment; filename="draft-boucadair-port-range-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItcG9ydC1yYW5nZS0wMS50eHQNCg== ------_=_NextPart_001_01C982C3.DCA67318 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara ------_=_NextPart_001_01C982C3.DCA67318-- From shara-bounces@ietf.org Fri Jan 30 02:46:28 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81F028C211; Fri, 30 Jan 2009 02:46:28 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D6583A692A for ; Fri, 30 Jan 2009 02:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhlfe3OU4-J5 for ; Fri, 30 Jan 2009 02:46:27 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3C3A128C211 for ; Fri, 30 Jan 2009 02:46:01 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DA4BB215D2; Fri, 30 Jan 2009 11:45:41 +0100 (CET) X-AuditID: c1b4fb3e-aa867bb00000429e-bc-4982da556ab3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BD43A212BF; Fri, 30 Jan 2009 11:45:41 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 11:45:41 +0100 Received: from [147.214.183.23] ([147.214.183.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 11:45:41 +0100 Message-ID: <4982DA55.5080602@ericsson.com> Date: Fri, 30 Jan 2009 11:45:41 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: In-Reply-To: X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 30 Jan 2009 10:45:41.0358 (UTC) FILETIME=[E54818E0:01C982C7] X-Brightmail-Tracker: AAAAAA== Cc: shara@ietf.org Subject: Re: [shara] Updated BOF proposal X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org teemu.savolainen@nokia.com skrev: > Hi, > = > IMHO there's third: we look at solution proposals currently not worked on= elsewhere and during WG work pick the one that fulfills the agreed require= ments best (including requirements of timing and complementing of existing = solutions). > = > That is why this is currently openly scoped. > = > Personally, I can agree on focusing this BOF to just "port ranges" and th= en discuss on details of how that is accomplished (e.g. With DHCP). But I p= refer having rough consensus on the scope instead of just pushing for what = I myself prefer. > = > I'd love to see opinions from still more people reading this list. Yes, I think this is an very important question that needs to be figured out about the scope. I think the description needs to be clear that it currently proposes an evaluate and pick phase on the solution. I think what technologies that are applicable to this is very depending on the problem one tries to solve. One of the big questions I have on the problem statement is what classes of legacy application you intended to support. Legacy client to sever application where the client towards the external uses an fractional address and which doesn't matter. Works fine with any allocation of address. Legacy application that have some IPv4 NAT traversal capabilities but still some specific requirements like particular port ranges or adjacent ports. Can they still work under a limited port range? Or do you need to capability to request and assign specific ports? Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From shara-bounces@ietf.org Fri Jan 30 04:35:59 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17313A68B9; Fri, 30 Jan 2009 04:35:59 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62053A6B34 for ; Fri, 30 Jan 2009 04:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeDt3khkFTYZ for ; Fri, 30 Jan 2009 04:35:54 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E65A03A68B9 for ; Fri, 30 Jan 2009 04:35:53 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0UCZHrK001712; Fri, 30 Jan 2009 14:35:24 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jan 2009 14:35:08 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jan 2009 14:35:03 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jan 2009 14:34:58 +0200 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 30 Jan 2009 13:34:58 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Fri, 30 Jan 2009 13:34:57 +0100 From: To: Date: Fri, 30 Jan 2009 13:34:33 +0100 Thread-Topic: [shara] Updated BOF proposal Thread-Index: AcmCx/lVv/GePSsuRb66I/498cU7SQACxQxQ Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E865B300@NOK-EUMSG-01.mgdnok.nokia.com> References: <4982DA55.5080602@ericsson.com> In-Reply-To: <4982DA55.5080602@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2009 12:34:58.0259 (UTC) FILETIME=[297FCA30:01C982D7] X-Nokia-AV: Clean Cc: shara@ietf.org Subject: Re: [shara] Updated BOF proposal X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org Hi, >I think this is an very important question that needs to be >figured out about the scope. I think the description needs to >be clear that it currently proposes an evaluate and pick phase >on the solution. I will clarify this to the proposal draft on Monday, with the comments received by that time. At this point as far as I know the actual proposals are: 1) Transport layer protocol based multiplexing. There will be new draft early next week that combines and evolves draft-boucadair-dhc-port-range and draft-bajko-v6ops-port-restricted-ipaddr-assign, and which proposes using new DHCP options to achieve assignment of port-restricted IPv4 addresses (while of course other address assigning protocols could be extended as well) 2) SAM (draft-despres-sam) 3) IPv4 address + bits from Identification field (no draft) >I think what technologies that are applicable to this is very >depending on the problem one tries to solve. One of the big >questions I have on the problem statement is what classes of >legacy application you intended to support. > >Legacy client to sever application where the client towards >the external uses an fractional address and which doesn't >matter. Works fine with any allocation of address. For this class of applications the benefits would be distribution of NAT to/toward edges instead of core. This is one of big benefits, I believe. >Legacy application that have some IPv4 NAT traversal >capabilities but still some specific requirements like >particular port ranges or adjacent ports. Can they still work >under a limited port range? Or do you need to capability to >request and assign specific ports? Generally these proposals would not provide all the benefits of IPv4, thus we recommend moving to IPv6 as fast as possible. In worst case the legacy application would face the same environment as with any NATed access, as the port restricted IPv4 address can be hidden from these applications by host-internal NAT. Thus applications trying to utilize specific ports (like IANA assigned) or port ranges would face similar trouble as when trying to work with privacy addresses. Thus the proposals shuld not be making life more difficult for unmodified apps. However, a modified application could gain at least following benefits over NATed address (on the drafts listed as reading there are probably more that I immediately recall): - host a server in one of the allocated public ports (provided rendezvous protocols allow communication of port as well) -> similar functionality is possible with UPnP/NAT-PMP, provided NAT allows control - which it always does not - avoid use of STUN, as the public address would be known already - perhaps fasten ICE procedures, if address candidate set would be smaller - avoid sending of NAT-keepalives (may still need firewall keepalives..) Now depending on proposal there is or is not possibility to get adjacent ports. I had forgotten that requirement of some real-time (right?) apps. I have never really understood why the adjacent port design was made - it makes implementations more complex. Is it to simplify creation of ALGs/firewall rules? That could be a problem to be sorted out. Best regards, Teemu _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara