From Marc.Blanchet@viagenie.ca Thu Oct 4 15:59:20 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD5221F862B for ; Thu, 4 Oct 2012 15:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXYHQ9nnAePR for ; Thu, 4 Oct 2012 15:59:20 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D1ED221F84FE for ; Thu, 4 Oct 2012 15:59:19 -0700 (PDT) Received: from [10.104.0.108] (unknown [75.98.19.134]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BAC144135B for ; Thu, 4 Oct 2012 18:59:18 -0400 (EDT) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_21DFEB72-CECE-420E-B596-FA22B5E00139" Date: Thu, 4 Oct 2012 18:59:17 -0400 References: <20121004185304.13152.78099.idtracker@ietfa.amsl.com> To: sunset4@ietf.org Message-Id: <3EC78A97-E350-4D10-8708-51987464FC1D@viagenie.ca> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [sunset4] Fwd: sunset4 - Requested session has been scheduled for IETF 85 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:59:20 -0000 --Apple-Mail=_21DFEB72-CECE-420E-B596-FA22B5E00139 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 FYI. as usual, scheduling may change. Marc. D=E9but du message r=E9exp=E9di=E9 : > De : "\"IETF Secretariat\"" > Objet : sunset4 - Requested session has been scheduled for IETF 85 > Date : 4 octobre 2012 14:53:04 HAE > =C0 : Marc.Blanchet@viagenie.ca > Cc : sunset4-ads@tools.ietf.org, Marc.Blanchet@viagenie.ca, = wesley.george@twcable.com, wlo@amsl.com >=20 > Dear Marc Blanchet, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request.=20 >=20 > sunset4 Session 1 (2:00:00) > Monday, Afternoon Session II 1520-1720 > Room Name: Salon D > --------------------------------------------- >=20 >=20 >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name:=20 > Area Name:=20 > Session Requester:=20 >=20 > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 200 > Conflicts to Avoid:=20 > First Priority: behave softwire v6ops precis > Second Priority: dhc intarea > Third Priority: opsarea opsawg >=20 >=20 > Special Requests: >=20 > --------------------------------------------------------- --Apple-Mail=_21DFEB72-CECE-420E-B596-FA22B5E00139 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 FYI. = as usual, scheduling may change. Marc.

D=E9but du = message r=E9exp=E9di=E9 :

De : "\"IETF = Secretariat\"" <agenda@ietf.org>
Objet : sunset4 - = Requested session has been scheduled for IETF = 85
Date : 4 octobre 2012 14:53:04 HAE

Dea= r Marc Blanchet,

The session(s) that you have requested have been = scheduled.
Below is the scheduled session information followed = by
the original request.

sunset4 Session 1 (2:00:00)
=    Monday, Afternoon Session II 1520-1720
=    Room Name: Salon D
=    ---------------------------------------------


Request = Information:


--------------------------------------------------= -------
Working Group Name:
Area Name:
Session Requester: =

Number of Sessions: 1
Length of Session(s):  2 = Hours
Number of Attendees: 200
Conflicts to Avoid:
First = Priority: behave softwire v6ops precis
Second Priority: dhc = intarea
Third Priority: opsarea opsawg


Special = Requests:

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

= --Apple-Mail=_21DFEB72-CECE-420E-B596-FA22B5E00139-- From akaliwod@cisco.com Fri Oct 5 06:12:52 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1332621F870F for ; Fri, 5 Oct 2012 06:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnY++HRX5aMJ for ; Fri, 5 Oct 2012 06:12:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C0BEB21F870E for ; Fri, 5 Oct 2012 06:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2764; q=dns/txt; s=iport; t=1349442770; x=1350652370; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aICDUB5NKpoRevvYMhlr8VZdGPiDObWEMlhnqHYhbSE=; b=hBe8McwGlY1FNZS0w5DYC2n3cEhF69oKBCzHu12QA72Ka1mdHNyr6thK nz3tsPaS6VzQf/NVVVNt5rdeNfJoqegNoRMim81Vz+Wa3MKhQpxOIGcTb rLudazaQ80Ra+7vy7Ls88RXk6/x0QiFnlKzzArVpex/IN0rtknU+6Pm7i Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPXbblCtJXG+/2dsb2JhbABFhhC4EnyBCIIgAQEBBBIBEBFDAgwEAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBA4FCAEZh2MLmBuNG5JxgSGKHYR3MmADlwCNMIFpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="128687751" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 05 Oct 2012 13:12:48 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q95DCmod027265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2012 13:12:48 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.206]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 08:12:48 -0500 From: "Arkadiusz Kaliwoda (akaliwod)" To: "sunset4@ietf.org" Thread-Topic: New Version Notification for draft-kaliwoda-sunset4-dual-ipv6-coexist-01.txt Thread-Index: AQHNovlbhojsQfn+40SazkWVb+dnVZeqrQGA Date: Fri, 5 Oct 2012 13:12:47 +0000 Message-ID: References: <20121005130007.25686.14734.idtracker@ietfa.amsl.com> In-Reply-To: <20121005130007.25686.14734.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.82.64] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001 x-tm-as-result: No--31.771500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "david.binet@orange.com" Subject: [sunset4] FW: New Version Notification for draft-kaliwoda-sunset4-dual-ipv6-coexist-01.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:12:52 -0000 SGkgQWxsLA0KDQpUaGUgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LCBub3cgY28tYXV0aG9yZWQg YnkgRGF2aWQgQmluZXQgYW5kIG15c2VsZiwgaGFzIGp1c3QgYmVlbiBzdWJtaXR0ZWQuIFRoZSBt YWluIGNoYW5nZSBpcyBleHRlbmRpbmcgdGhlIHNjb3BlIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVu dCB0byB0aGUgbW9iaWxlIG5ldHdvcmsgYW5kIGNlbGx1bGFyIGhvc3RzLCBob3BlZnVsbHkgbWFr aW5nIGl0IG1vcmUgY29tcGxldGUuDQogDQpQbGVhc2UgZmluZCB0aGUgbGlua3MgdG8gdGhlIGRv Y3VtZW50IGFuZCBhYnN0cmFjdCBiZWxvdy4gDQoNClRoYW5rIHlvdSBmb3IgcmV2aWV3IG9mIHRo ZSBkcmFmdCBhbmQgeW91ciBjb21tZW50cy4NCg0KUmVnYXJkcw0KRGF2aWQgYW5kIEthbGkNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIE9jdG9i ZXIgMDUsIDIwMTIgMzowMCBQTQ0KVG86IEFya2FkaXVzeiBLYWxpd29kYSAoYWthbGl3b2QpDQpD YzogZGF2aWQuYmluZXRAb3JhbmdlLmNvbQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1rYWxpd29kYS1zdW5zZXQ0LWR1YWwtaXB2Ni1jb2V4aXN0LTAxLnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1rYWxpd29kYS1zdW5zZXQ0LWR1YWwtaXB2 Ni1jb2V4aXN0LTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBcmth ZGl1c3ogS2FsaXdvZGEgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxl bmFtZToJIGRyYWZ0LWthbGl3b2RhLXN1bnNldDQtZHVhbC1pcHY2LWNvZXhpc3QNClJldmlzaW9u OgkgMDENClRpdGxlOgkJIENvLWV4aXN0ZW5jZSBvZiBib3RoIGR1YWwtc3RhY2sgYW5kIElQdjYt b25seSBob3N0cw0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMTAtMDUNCldHIElEOgkJIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA5DQpVUkw6ICAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWthbGl3b2RhLXN1bnNldDQtZHVh bC1pcHY2LWNvZXhpc3QtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQta2FsaXdvZGEtc3Vuc2V0NC1kdWFsLWlwdjYtY29leGlzdA0K SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rYWxpd29k YS1zdW5zZXQ0LWR1YWwtaXB2Ni1jb2V4aXN0LTAxDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWthbGl3b2RhLXN1bnNldDQtZHVhbC1pcHY2 LWNvZXhpc3QtMDENCg0KQWJzdHJhY3Q6DQogICBTb21lIG5ldHdvcmtzIGFyZSBleHBlY3RlZCB0 byBzdXBwb3J0IElQdjQtb25seSwgZHVhbC1zdGFjaywgYW5kDQogICBJUHY2LW9ubHkgaG9zdHMg YXQgdGhlIHNhbWUgdGltZS4gIFN1Y2ggbmV0d29ya3MgbWF5IHdhbnQgdG8gYWRkDQogICBJUHY2 L0lQdjQgdHJhbnNsYXRpb24gZm9yIHRoZSBJUHY2LW9ubHkgaG9zdCBzbyBpdCBjYW4gYWNjZXNz IHNlcnZlcnMNCiAgIG9uIHRoZSBJUHY0IEludGVybmV0LiAgQWRkaW5nIHRyYW5zbGF0aW9uIHNl cnZpY2UgdG8gdGhlIElQdjYtZW5hYmxlZA0KICAgbmV0d29yayBtYXkgY2hhbmdlIGR1YWwtc3Rh Y2sgaG9zdCBiZWhhdmlvciBhbmQgYWZmZWN0IHRoZSB3YXkNCiAgIGRlcGxveWVkIG5ldHdvcmsg aXMgd29ya2luZy4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgcHJvYmxlbQ0KICAgc3RhdGVt ZW50IGZvciBzdWNoIG5ldHdvcmtzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From simon.perreault@viagenie.ca Mon Oct 15 05:52:38 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8936B21F8758 for ; Mon, 15 Oct 2012 05:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm+pHvSGNn4M for ; Mon, 15 Oct 2012 05:52:37 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D474921F875A for ; Mon, 15 Oct 2012 05:52:37 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:3455:c3c1:67db:723]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4140E419E1 for ; Mon, 15 Oct 2012 08:52:37 -0400 (EDT) Message-ID: <507C0714.5070603@viagenie.ca> Date: Mon, 15 Oct 2012 08:52:36 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: "sunset4@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sunset4] On-Demand Provisioning of IPv4 Addresses X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 12:52:38 -0000 All, Cathy Zhou sent me the following addition to the IPv4 sunset gap analysis draft. Unless the WG disagrees, I will add it to the -01 revision (to be published before the IETF85 deadline). Please also feel free to comment on the technical issue itself. Thanks, Simon > 6. On-Demand Provisioning of IPv4 Addresses > > As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers > will become smaller. This could be exploited by an ISP to save IPv4 > addresses by provisioning them on-demand to subscribers and > reclaiming them when they are no longer used. This idea is described > in [I-D.fleischhauer-ipv4-addr-saving] and [BBF.TR242] for the > context of PPP sessions. In these scenarios, the home router is > responsible for requesting and releasing IPv4 addresses, based on > snooping the traffic generated by the hosts in the LAN, which are > still dual-stack and unaware that their traffic is being snooped. > > PROBLEM 9: Dual-stack hosts that implement Happy-Eyeballs [RFC6555] > will generate both IPv4 and IPv6 traffic even if the > algorithm end up chooosing IPv6. This means that an > IPv4 address will always be requested by the home > router, which defeats the purpose of on-demand > provisioning. > > PROBLEM 10: Many operating systems periodically perform some kind of > network connectivity check as long as an interface is > up. Similarly, applications often send keep-alive > traffic continuously. This permanent "background noise" > will prevent an IPv4 address from being released by the > home router. > > PROBLEM 11: Hosts in the LAN have no knowledge that IPv4 is > available to them on-demand only. If they had explicit > knowledge of this fact, they could tune their behaviour > so as to be more conservative in their use of IPv4. > > PROBLEM 12: This mechanism is only being proposed for PPP even > though it could apply to other provisioning protocols > (e.g., DHCP). -- 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 phdgang@gmail.com Mon Oct 15 08:59:24 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BF21F0C5F for ; Mon, 15 Oct 2012 08:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NhFQCRcrQjU for ; Mon, 15 Oct 2012 08:59:23 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3B31F042B for ; Mon, 15 Oct 2012 08:59:23 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6617615vcb.31 for ; Mon, 15 Oct 2012 08:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jvya+k1/vLjlhId5NqxmBmcaGarZipTfoi96hVtlUCo=; b=BW4JLzDMraPsjwrNTQnwF4HSqts7AOOguyAWbu54NrVVkT6tgmpkRf4z0Wen5odCAQ xW4qtSm2Lku96Qf7poKGli0JXoWsAmFShmapF+7nR4m/qP7kJ0EUo6wKQ7fAOlpnylBP Bw2J+XoctNB7BNLrn5JauVw0wpfwVBbZkt69wsj1sBRbdqFciXxP6RInv9A+lc/9xlrm +L0Ugw5DON9A+mH6umPj3/Imd1eOWuEvsZ6EvbffcuHPCyYxehplUwk62wxMfdIcmi5C Ut5qRF/MVppT/MLM3PzMeVSij3x10UrRKK7jtR/kbq/Mrpswt1WQQiawcCgsqtOo7NI2 WCaQ== MIME-Version: 1.0 Received: by 10.220.240.135 with SMTP id la7mr6888101vcb.44.1350316762481; Mon, 15 Oct 2012 08:59:22 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Mon, 15 Oct 2012 08:59:22 -0700 (PDT) In-Reply-To: <20121015144832.27917.82392.idtracker@ietfa.amsl.com> References: <20121015144832.27917.82392.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 23:59:22 +0800 Message-ID: From: GangChen To: "sunset4@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [sunset4] Fwd: I-D Action: draft-chen-sunset4-traffic-migration-00.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:59:24 -0000 Hello all, New draft has been just submitted in order to achieve a graceful IPv4 sunset depending on the methods of traffic steering. The link and more information are shown as below. Your comments and review are appreciated. Many thanks Gang ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Mon, 15 Oct 2012 07:48:32 -0700 Subject: I-D Action: draft-chen-sunset4-traffic-migration-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Graceful IPv4 Sunset with Traffic Migration Author(s) : Gang Chen Filename : draft-chen-sunset4-traffic-migration-00.txt Pages : 8 Date : 2012-10-15 Abstract: In order to make a graceful IPv4 sunset, this memo described a method helping traffic migration to IPv6. With the growth of IPv6 traffic, operators could safely turn off IPv4 and evolve to IPv6-only network. In order to achieve the goal, new traffic-migration options have been proposed in DHCPv6 and PCP. IPv6 traffic steering could be performed using those configurations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-sunset4-traffic-migration There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-sunset4-traffic-migration-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 From yangtianle@chinamobile.com Thu Oct 18 23:24:34 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC89D21F85AF for ; Thu, 18 Oct 2012 23:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.34 X-Spam-Level: **** X-Spam-Status: No, score=4.34 tagged_above=-999 required=5 tests=[AWL=2.116, BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEvyoL8W9eKI for ; Thu, 18 Oct 2012 23:24:33 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4E95721F8206 for ; Thu, 18 Oct 2012 23:24:33 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 2B478E7DB for ; Fri, 19 Oct 2012 14:24:32 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 07C3CE7D6 for ; Fri, 19 Oct 2012 14:24:32 +0800 (CST) Received: from yangtianle ([10.2.54.23]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012101914242853-17250 ; Fri, 19 Oct 2012 14:24:28 +0800 From: "yangtianle" To: Date: Fri, 19 Oct 2012 14:24:14 +0800 Message-ID: <002d01cdadc2$5bf117c0$13d34740$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2twlvK7iL5AHbxSluCBn4QXTwgcA== X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-10-19 14:24:28, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-10-19 14:24:31, Serialize complete at 2012-10-19 14:24:31 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CDAE05.6A1457C0" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19288.000 X-TM-AS-Result: No--27.328-7.0-31-10 X-imss-scan-details: No--27.328-7.0-31-10;No--27.328-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [sunset4] draft-yang-sunset4-weaken-dhcp-00 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 06:24:35 -0000 这是一封 MIME 格式的多部分邮件。 ------=_NextPart_000_002E_01CDAE05.6A1457C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="gb2312" Hi=A3=ACall =20 New draft =A1=B0draft-yang-sunset4-weaken-dhcp-00=A1=B1 had been = submitted . =20 It focus on turning off or weakening DHCP by deploying new defined = option in DHCPv6 or RA.=20 =20 Appreciating for your comments and review. =20 =20 Tianle Yang =20 =20 =20 =20 =20 ------=_NextPart_000_002E_01CDAE05.6A1457C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"

Hi=A3=ACall

 

New draft = =A1=B0draft-yang-sunset4-weaken-dhcp-00=A1=B1 had been submitted .

 

It focus on turning off or = weakening DHCP by deploying new defined option in DHCPv6 or RA.

 

Appreciating for your comments = and review.

 

 

Tianle = Yang

 

 

 

 

 

------=_NextPart_000_002E_01CDAE05.6A1457C0-- From internet-drafts@ietf.org Mon Oct 22 07:17:43 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86E21F8BBA; Mon, 22 Oct 2012 07:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQj2B7+ZBKMh; Mon, 22 Oct 2012 07:17:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F5321F8A0F; Mon, 22 Oct 2012 07:17:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022141742.31140.28800.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 07:17:42 -0700 Cc: sunset4@ietf.org Subject: [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-01.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:17:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Sunsetting IPv4 Working Group of the IETF. Title : Gap Analysis for IPv4 Sunset Author(s) : Jean-Philippe Dionne Simon Perreault Tina Tsou Cathy Zhou Filename : draft-ietf-sunset4-gapanalysis-01.txt Pages : 9 Date : 2012-10-22 Abstract: Sunsetting IPv4 refers to the process of turning off IPv4 definitively. It can be seen as the final phase of the migration to IPv6. This memo analyses difficulties arising when sunsetting IPv4, and identifies the gaps resulting in additional work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sunset4-gapanalysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sunset4-gapanalysis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Mon Oct 22 07:27:52 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092F021F88F1 for ; Mon, 22 Oct 2012 07:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I4RkUDn0IdU for ; Mon, 22 Oct 2012 07:27:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC4921F88F8 for ; Mon, 22 Oct 2012 07:27:51 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8c54:f483:a6fd:5c0]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9264045BD2 for ; Mon, 22 Oct 2012 10:27:48 -0400 (EDT) Message-ID: <508557E3.2030307@viagenie.ca> Date: Mon, 22 Oct 2012 10:27:47 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: sunset4@ietf.org References: <20121022141742.31140.28800.idtracker@ietfa.amsl.com> In-Reply-To: <20121022141742.31140.28800.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-01.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:27:52 -0000 In this revision we added section "6. On-Demand Provisioning of IPv4 Addresses", as announced in an earlier email. Simon Le 2012-10-22 10:17, internet-drafts@ietf.org a 閏rit : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Sunsetting IPv4 Working Group of the IETF. > > Title : Gap Analysis for IPv4 Sunset > Author(s) : Jean-Philippe Dionne > Simon Perreault > Tina Tsou > Cathy Zhou > Filename : draft-ietf-sunset4-gapanalysis-01.txt > Pages : 9 > Date : 2012-10-22 > > Abstract: > Sunsetting IPv4 refers to the process of turning off IPv4 > definitively. It can be seen as the final phase of the migration to > IPv6. This memo analyses difficulties arising when sunsetting IPv4, > and identifies the gaps resulting in additional work. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sunset4-gapanalysis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sunset4-gapanalysis-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > -- 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 Mon Oct 22 07:43:05 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B4621F8BB3 for ; Mon, 22 Oct 2012 07:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmAvxN-2wQ7P for ; Mon, 22 Oct 2012 07:43:04 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 55D7621F8BAF for ; Mon, 22 Oct 2012 07:43:04 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8c54:f483:a6fd:5c0]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 63CF544A83 for ; Mon, 22 Oct 2012 10:43:03 -0400 (EDT) Message-ID: <50855B76.2030704@viagenie.ca> Date: Mon, 22 Oct 2012 10:43:02 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: "sunset4@ietf.org" References: <20121022142616.31131.14365.idtracker@ietfa.amsl.com> In-Reply-To: <20121022142616.31131.14365.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121022142616.31131.14365.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [sunset4] Fwd: New Version Notification for draft-perreault-sunset4-noipv4-01.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:43:05 -0000 We have modified our draft on turning off IPv4 using DHCPv6 following the comments received at last IETF: - Added a new section describing the problems we're trying to fix. - Created a new "softer" v4-level value advertising the absence of IPv4 on the WAN with zero impact on the LAN, as asked by WG participants. Simon -------- Message original -------- Sujet: New Version Notification for draft-perreault-sunset4-noipv4-01.txt Date : Mon, 22 Oct 2012 07:26:16 -0700 De : internet-drafts@ietf.org Pour : simon.perreault@viagenie.ca Copie 脿 : wesley.george@twcable.com, tina.tsou.zouting@huawei.com A new version of I-D, draft-perreault-sunset4-noipv4-01.txt has been successfully submitted by Simon Perreault and posted to the IETF repository. Filename: draft-perreault-sunset4-noipv4 Revision: 01 Title: Turning off IPv4 Using DHCPv6 Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-perreault-sunset4-noipv4-01.txt Status: http://datatracker.ietf.org/doc/draft-perreault-sunset4-noipv4 Htmlized: http://tools.ietf.org/html/draft-perreault-sunset4-noipv4-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-perreault-sunset4-noipv4-01 Abstract: This memo defines a new DHCPv6 option for indicating to a dual-stack host or router that IPv4 is to be turned off. The IETF Secretariat From marc.blanchet@viagenie.ca Mon Oct 22 12:01:51 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC06F21F8A25 for ; Mon, 22 Oct 2012 12:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZcEYj-oskRa for ; Mon, 22 Oct 2012 12:01:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D711B21F858B for ; Mon, 22 Oct 2012 12:01:36 -0700 (PDT) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AB9DD40167 for ; Mon, 22 Oct 2012 15:01:32 -0400 (EDT) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Oct 2012 15:01:32 -0400 Message-Id: To: sunset4@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [sunset4] new charter draft version X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 19:01:51 -0000 Hello, a few individuals worked on a new version of the sunset4 charter after = the last IETF. It has been wordsmitted many times and hopefully would = get support from the working group.=20 It would be useful for us to see if you support this charter. If you = disagree, it would be useful to get modified text.=20 Marc and Wes. PS. Current charter is still at the normal place: = https://datatracker.ietf.org/doc/charter-ietf-sunset4/ PS2. this new charter has not got through IESG review yet. =3D=3D=3D=3D=3D=3D=3D New sunset4 proposed charter=20 2012-10-22 Global IPv4 addresses, once freely available, are an increasingly scarce = resource for many who wish to connect to the Internet today. IPv6 = provides an abundance of freely available addresses, and while = deployment alongside IPv4 has begun in earnest, much work remains. In order to fully transition the Internet to IPv6, individual = applications, hosts, and networks that have enabled IPv6 must also be = able to operate fully in the absence of IPv4. The Working Group will = point out specific areas of concern, provide recommendations, and = standardize protocols that facilitate the graceful "sunsetting" of the = IPv4 Internet in areas where IPv6 has been deployed. This includes the = act of shutting down IPv4 itself, as well as the ability of IPv6-only = portions of the Internet to continue to connect with portions of the = Internet that remain IPv4-only.=20 While this work obviously spans multiple IETF areas including Internet, = Operations, Transport, Applications, and Routing, this working group = provides a single venue for the consideration of IPv4 sunsetting. Work = in this group shall never impede the deployment of IPv6, will not = duplicate functions and capabilities already available in existing = technologies, and should demonstrate widespread operational need. = Cross-area coordination and support is essential. Disabling IPv4 in applications, hosts, and networks is new territory for = much of the Internet today, and it is expected that problems will be = uncovered including those related to basic IPv4 functionality, = interoperability, as well as potential security concerns. The working = group will report on common issues, provide recommendations, and, when = necessary, protocol extensions in order to facilitate disabling IPv4 in = networks where IPv6 has been deployed. As a rule, deployment scenarios considered by the working group shall = include IPv6-only nodes and networks. Work on technologies that involve = increased sharing of global IPv4 addresses should be limited to what is = necessary for communicating with endpoints or over networks that are = IPv6-only.=20 The initial work items are: * NAT64 port allocation and address sharing methods involving scenarios = where an IPv6-only node is present (and NAT44, as it overlaps NAT64 = address sharing and port use). * Gap analysis of IPv4 features to facilitate IPv4 sunsetting * Provisioning methods to signal a dual-stack host to disable or = depreference the use of IPv4 Goals and Milestones: Mar 2013 - Submit gap analysis on IPv4 sunsetting to IESG for = consideration as an Informational RFC Jun 2013 - Submit NAT64 port allocation and address sharing methods to = IESG for consideration as an Informational RFC Sep 2013 - Submit provisioning methods to signal a dual-stack host to = disable the use of IPv4 to IESG for consideration as Proposed Standard= From marc.blanchet@viagenie.ca Mon Oct 22 12:07:17 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C84F21F8B70 for ; Mon, 22 Oct 2012 12:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8I1INTzBAnz for ; Mon, 22 Oct 2012 12:07:17 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E1F4221F8B60 for ; Mon, 22 Oct 2012 12:07:16 -0700 (PDT) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4E4A544A83; Mon, 22 Oct 2012 15:07:16 -0400 (EDT) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Oct 2012 15:07:15 -0400 Message-Id: <6B151CCC-4170-4201-B6E4-D3ECA08AA3B2@viagenie.ca> To: sunset4@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: sunset4-chairs@tools.ietf.org Subject: [sunset4] Atlanta IETF call for meeting slot X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 19:07:17 -0000 Hello, if you would like to present at the Atlanta IETF, please send your = request to the chairs, with name, draft reference, time requested.=20 sunset4-chairs@tools.ietf.org Marc & Wes.= From wesley.george@twcable.com Mon Oct 22 13:04:46 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF1421F87AA for ; Mon, 22 Oct 2012 13:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAchEDWSAOQZ for ; Mon, 22 Oct 2012 13:04:45 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C4B6921F879B for ; Mon, 22 Oct 2012 13:04:44 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,631,1344225600"; d="scan'208";a="438874032" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Oct 2012 16:02:42 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 22 Oct 2012 16:04:01 -0400 From: "George, Wes" To: GangChen , "sunset4@ietf.org" Date: Mon, 22 Oct 2012 16:04:00 -0400 Thread-Topic: [sunset4] Fwd: I-D Action: draft-chen-sunset4-traffic-migration-00.txt Thread-Index: Ac2q7lBliMwyg7f3SGKry7BSXrUNGgFnQdZA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592303368EA55F@PRVPEXVS15.corp.twcable.com> References: <20121015144832.27917.82392.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sunset4] Fwd: I-D Action: draft-chen-sunset4-traffic-migration-00.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 20:04:46 -0000 Hi - I've reviewed your draft, apologies that I didn't get to this in time for y= ou to push a revision before Atlanta, I've been out for medical reasons and= indeed will be attending the next IETF remotely as a result. First, I'd note that I-Ds don't normally reference specific WGs in the text= , because WGs and their charters tend to be ephemeral when compared with th= eir RFC output, so it's more effective to discuss specifically the problem = being solved without reference to the WG that may or may not exist to solve= it. Regarding the second paragraph of your introduction- I'm unclear why you re= ferenced dual-stack here. It'd be helpful to be more explicit about the fac= t that dual-stack is a transition point itself, and the goal is single-stac= k IPv6 (as you state in the beginning of section 3) and lead the reader to = the conclusion you're drawing by including the discussion about dual-stack,= or possibly remove it. I think section 3 is a little out of place in this document - there are man= y documents covering transition mechanisms to manage carrying IPv4 over an = IPv6 network, we don't need to revisit them in sunset4. I like the idea of presenting different ways to push traffic towards IPv6 i= n hosts where there is an option, in fact, that is one of the things we add= ed to the charter in the last revision. Basically the question is, "how do = you signal a preference between IPv4 or IPv6 to dual-stack hosts?" and a fo= llow-on question might be "how granular does that signaling need to be?" I think draft-perreault-sunset4-noipv4 talks about one way, draft-kaliwoda-= sunset4-dual-ipv6-coexist talks about some other aspects of it, and other b= its may be in the gap analysis draft, and there have been previous discussi= ons on other WG lists about whether happy eyeballs is enough by itself, or = whether one should induce delay to affect happy eyeballs' choice of protoco= l. Ultimately, it's going to be important to have a way to communicate busi= ness rules assuming that networks will have varying methods of carrying IPv= 4 traffic (including NAT that may make it a secondary choice) and providing= IPv6 access to IPv4-only content or devices (ex NAT64, etc) such that with= out some additional guidance, the end hosts may make the wrong choice about= which address family to use and the customer will get adverse service due = to capacity limitations, translation issues, etc. I think the WG needs to decide how to structure drafts discussing and solvi= ng this exact problem - my initial thought would be to document the protoco= ls where it would make sense to be able to communicate this preference with= in the gap analysis, and then once we have consensus on where, then we writ= e drafts to propose the features and option codes necessary to make that wo= rk in the different protocols. This is especially true where we're recommen= ding changes to protocols that are under the purview of another WG - we wan= t to be able to send them a draft that covers the changes we propose and wh= y we propose them in a relatively self-contained manner for ease of review = (vs one draft that proposes changes to several protocols simultaneously). But I'm open to alternate suggestions by other members of the WG - I'd like= to get some discussion going... Thanks, Wes George > -----Original Message----- > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On > Behalf Of GangChen > Sent: Monday, October 15, 2012 11:59 AM > To: sunset4@ietf.org > Subject: [sunset4] Fwd: I-D Action: draft-chen-sunset4-traffic- > migration-00.txt > > Hello all, > > New draft has been just submitted in order to achieve a graceful IPv4 > sunset depending on the methods of traffic steering. > > The link and more information are shown as below. > > Your comments and review are appreciated. > > Many thanks > > Gang > > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > Date: Mon, 15 Oct 2012 07:48:32 -0700 > Subject: I-D Action: draft-chen-sunset4-traffic-migration-00.txt > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Graceful IPv4 Sunset with Traffic Migration > Author(s) : Gang Chen > Filename : draft-chen-sunset4-traffic-migration-00.txt > Pages : 8 > Date : 2012-10-15 > > Abstract: > In order to make a graceful IPv4 sunset, this memo described a method > helping traffic migration to IPv6. With the growth of IPv6 traffic, > operators could safely turn off IPv4 and evolve to IPv6-only network. > In order to achieve the goal, new traffic-migration options have been > proposed in DHCPv6 and PCP. IPv6 traffic steering could be performed > using those configurations. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-chen-sunset4-traffic-migration > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-chen-sunset4-traffic-migration-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From liushucheng@huawei.com Mon Oct 22 19:11:10 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B17821F8437 for ; Mon, 22 Oct 2012 19:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAmP9h+dPHA3 for ; Mon, 22 Oct 2012 19:11:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 79E891F0C54 for ; Mon, 22 Oct 2012 19:11:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKV76158; Tue, 23 Oct 2012 02:11:08 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 03:11:01 +0100 Received: from SZXEML447-HUB.china.huawei.com (10.82.67.185) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 03:11:07 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml447-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 10:10:51 +0800 From: "Will Liu (Shucheng)" To: "sunset4@ietf.org" Thread-Topic: New Version Notification for draft-tsou-stateless-nat44-02.txt Thread-Index: AQHNsGOY9qFlfx8lCUyydwjdtaZtVZfGItSw Date: Tue, 23 Oct 2012 02:10:51 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [sunset4] FW: New Version Notification for draft-tsou-stateless-nat44-02.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 02:11:10 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIG1vZGlmaWVkIG91ciBzdGF0ZWxlc3MgTkFUNDQgZHJhZnQgYXMg Zm9sbG93Og0KDQotIEFkZGVkIGEgYnJpZGdlIG1vZGUgaW50byAiQ1BFIG9wZXJhdGlvbiIsIGlu IHdoaWNoIGludGVybmFsIGFkZHJlc3NlcyBhcmUgZGlyZWN0bHkgYXNzaWduZWQgdG8gdGhlIGVu ZCBob3N0cyBpbiB0aGUgaG9tZSBuZXR3b3JrLg0KLSBNb2RpZmllZCB0aGUgIkNQRSBwcm92aXNp b25pbmciIHRvICJDdXN0b21lciBwcm92aXNpb25pbmciIGFzIHRoZSBvYmplY3QgY291bGQgYmUg ZWl0aGVyIENQRSBvciBlbmQgaG9zdC4NCi0gQWRkZWQgYSBwaWN0dXJlIGludG8gdGhlIGFyY2hp dGVjdHVyZSB3aGVyZSB0aGUgaG9tZSBuZXR3b3JrIGNhbiBoYXZlIHRoZSBpbnRlcm5hbCBhZGRy ZXNzZXMgZGlyZWN0bHkuDQoNCllvdXIgcmV2aWV3IGFuZCBjb21tZW50cyBhcmUgaGlnaGx5IGFw cHJlY2lhdGVkLiANCg0KV2lsbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddIA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDIyLCAyMDEyIDEwOjQzIFBNDQpUbzogV2lsbCBM aXUgKFNodWNoZW5nKQ0KQ2M6IHNpbW9uLnBlcnJlYXVsdEB2aWFnZW5pZS5jYTsgcmVwZW5ub0Bj aXNjby5jb207IGZpYnJpYkBnbWFpbC5jb207IFRpbmEgVFNPVQ0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10c291LXN0YXRlbGVzcy1uYXQ0NC0wMi50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdHNvdS1zdGF0ZWxlc3MtbmF0NDQtMDIudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdpbGwgTGl1IGFuZCBwb3N0ZWQg dG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtdHNvdS1zdGF0ZWxl c3MtbmF0NDQNClJldmlzaW9uOgkgMDINClRpdGxlOgkJIFN0YXRlbGVzcyBJUHY0IE5ldHdvcmsg QWRkcmVzcyBUcmFuc2xhdGlvbg0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMTAtMjINCldHIElEOgkJ IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMg0KVVJMOiAgICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10c291LXN0YXRl bGVzcy1uYXQ0NC0wMi50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC10c291LXN0YXRlbGVzcy1uYXQ0NA0KSHRtbGl6ZWQ6ICAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c291LXN0YXRlbGVzcy1uYXQ0NC0wMg0K RGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC10 c291LXN0YXRlbGVzcy1uYXQ0NC0wMg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgbWVtbyBkZXNjcmli ZXMgYSBwcm90b2NvbCBmb3IgZGVjZW50cmFsaXppbmcgSVB2NCBOQVQgdG8gdGhlDQogICBjdXN0 b21lci1wcmVtaXNlcyBlcXVpcG1lbnQgKENQRSkgc3VjaCB0aGF0IG5vIHN0YXRlIGluZm9ybWF0 aW9uIGlzDQogICBrZXB0IG9uIHRoZSBjZW50cmFsIE5BVCBkZXZpY2UuICBUaGUgQ1BFIHVzZXMg YSByZXN0cmljdGVkIHNvdXJjZQ0KICAgcG9ydCBzZXQgdGhhdCBpcyBlbmNvZGVkIGluIGl0cyBw cm92aXNpb25lZCBJUHY0IFdBTiBhZGRyZXNzLiAgVGhlDQogICBOQVQgZGV2aWNlIHBlcmZvcm1z IG9ubHkgc3RyaWN0bHkgc3RhdGVsZXNzIGFkZHJlc3MgKG5vdCBwb3J0KQ0KICAgdHJhbnNsYXRp b24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlh dA0KDQo= From phdgang@gmail.com Tue Oct 23 00:25:46 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD6C21F843C for ; Tue, 23 Oct 2012 00:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GIh7rvTolUh for ; Tue, 23 Oct 2012 00:25:45 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E07F021F843F for ; Tue, 23 Oct 2012 00:25:44 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4239394vcb.31 for ; Tue, 23 Oct 2012 00:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YtiT/8pXlnIQWlcwkg+bQ8ue41plHoE9BlC9ePOUrgI=; b=ic55/t4jTN0a8+8xT15vr/b8vrtCY9Ucu6w782MTLwFquvJN6tOGB80TXTbajz1ZHH epmWMYOf6HdPS4bJG6GMPT1FQgzp4SP4tFZskTw+A91DpMfnYs5DSdfo/n2QXQyFnNLf mo18kyf02jsZrk3hXydSSDeKkPUWSsRJkBIHVTX8z3lnzzwSfxKfVAa9J1zFzUODxYgf jrFuh43sOUKsgkBP5vk016ncBH1/LQVL2THHMgXKQh0NT0BStCsoVWs+yhRUiPbyK8SG oad0FusxCZEKxXWAxc37abVT6eOiaktyl+QGk6lp2D1uPq0sGs0GMmh1KwNvEWGtD0OP 7jsg== MIME-Version: 1.0 Received: by 10.220.210.193 with SMTP id gl1mr607586vcb.58.1350977144125; Tue, 23 Oct 2012 00:25:44 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Tue, 23 Oct 2012 00:25:44 -0700 (PDT) In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD592303368EA55F@PRVPEXVS15.corp.twcable.com> References: <20121015144832.27917.82392.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD592303368EA55F@PRVPEXVS15.corp.twcable.com> Date: Tue, 23 Oct 2012 15:25:44 +0800 Message-ID: From: GangChen To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Cc: "sunset4@ietf.org" Subject: Re: [sunset4] Fwd: I-D Action: draft-chen-sunset4-traffic-migration-00.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 07:25:46 -0000 2012/10/23, George, Wes : > Hi - > > I've reviewed your draft, apologies that I didn't get to this in time for > you to push a revision before Atlanta, I've been out for medical reasons and > indeed will be attending the next IETF remotely as a result. Thanks for the review and guidance. More replies are inline. > First, I'd note that I-Ds don't normally reference specific WGs in the text, > because WGs and their charters tend to be ephemeral when compared with their > RFC output, so it's more effective to discuss specifically the problem being > solved without reference to the WG that may or may not exist to solve it. ACKed. Will update it in the next version. > Regarding the second paragraph of your introduction- I'm unclear why you > referenced dual-stack here. It'd be helpful to be more explicit about the > fact that dual-stack is a transition point itself, and the goal is > single-stack IPv6 (as you state in the beginning of section 3) and lead the > reader to the conclusion you're drawing by including the discussion about > dual-stack, or possibly remove it. Good suggestion. The intention of texts is exactly what you described. Mentioning dual-stack intends to state the fact dual-stack may be the phase some operators adopted. It's required that sunset technologies positively enable the migration to IPv6-only mode. I would modify the texts by combining statements in paragraph 2 and 3. > I think section 3 is a little out of place in this document - there are many > documents covering transition mechanisms to manage carrying IPv4 over an > IPv6 network, we don't need to revisit them in sunset4. The draft cited RFC6264, because it explicitly provides an evolving path to IPv6-only stack. It may be useful hints to graceful IPv4 sunsets. In particular, the incremental IPv6 transition could be facilitated by a sunset technology. > I like the idea of presenting different ways to push traffic towards IPv6 in > hosts where there is an option, in fact, that is one of the things we added > to the charter in the last revision. Good to hear it. The point here is IPv4 sunset may be a soft-landing process. We managed to seek a way, which is safe, stable and acceptable for operators. Traffic steering may fit the goal, since it increases IPv6 usages with no risks to degration of customer's experiences. With the growth of IPv6 traffic, it serves a strong IPv6 sign to the industry. Application developer, ICP, OS provider, network provider, etc could be inspired to enable native IPv6 features. Single IPv6 deployment could be achieved with usages of transition mechanism going down. > Basically the question is, "how do you > signal a preference between IPv4 or IPv6 to dual-stack hosts?" and a > follow-on question might be "how granular does that signaling need to be?" That is a hard question. I also put a note in the draft and expect discussions from the group. I suppose selection of particular technology may not the goal of sunset4, neither in the draft. > I think draft-perreault-sunset4-noipv4 talks about one way, > draft-kaliwoda-sunset4-dual-ipv6-coexist talks about some other aspects of > it, and other bits may be in the gap analysis draft, and there have been > previous discussions on other WG lists about whether happy eyeballs is > enough by itself, or whether one should induce delay to affect happy > eyeballs' choice of protocol. Ultimately, it's going to be important to have > a way to communicate business rules assuming that networks will have varying > methods of carrying IPv4 traffic (including NAT that may make it a secondary > choice) and providing IPv6 access to IPv4-only content or devices (ex NAT64, > etc) such that without some additional guidance, the end hosts may make the > wrong choice about which address family to use and the customer will get > adverse service due to capacity limitations, translation issues, etc. I also agree a way to business rules is important. As you indicated, several drafts intend to provide these analysis about the gap/solutions between the bussines expectation and technical status. This draft basically want to initiate a discussion what's sunset4 process should be. Should it make a smooth enabler or prompt changes? > I think the WG needs to decide how to structure drafts discussing and > solving this exact problem - my initial thought would be to document the > protocols where it would make sense to be able to communicate this > preference within the gap analysis, and then once we have consensus on > where, then we write drafts to propose the features and option codes > necessary to make that work in the different protocols. This is especially > true where we're recommending changes to protocols that are under the > purview of another WG - we want to be able to send them a draft that covers > the changes we propose and why we propose them in a relatively > self-contained manner for ease of review (vs one draft that proposes changes > to several protocols simultaneously). > But I'm open to alternate suggestions by other members of the WG - I'd like > to get some discussion going... I think that is a good process from problem poking to solution designing. Only one point is to be clarified. If one goal could be fulfilled by several approaches and wg agree each of them has necessity, I guess document them in one draft may benefit to the legibility. Making a container requesting protocol changes is better than separated requests. Best Regards Gang BRs Gang > Thanks, > > Wes George > >> -----Original Message----- >> From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On >> Behalf Of GangChen >> Sent: Monday, October 15, 2012 11:59 AM >> To: sunset4@ietf.org >> Subject: [sunset4] Fwd: I-D Action: draft-chen-sunset4-traffic- >> migration-00.txt >> >> Hello all, >> >> New draft has been just submitted in order to achieve a graceful IPv4 >> sunset depending on the methods of traffic steering. >> >> The link and more information are shown as below. >> >> Your comments and review are appreciated. >> >> Many thanks >> >> Gang >> >> ---------- Forwarded message ---------- >> From: internet-drafts@ietf.org >> Date: Mon, 15 Oct 2012 07:48:32 -0700 >> Subject: I-D Action: draft-chen-sunset4-traffic-migration-00.txt >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Graceful IPv4 Sunset with Traffic Migration >> Author(s) : Gang Chen >> Filename : draft-chen-sunset4-traffic-migration-00.txt >> Pages : 8 >> Date : 2012-10-15 >> >> Abstract: >> In order to make a graceful IPv4 sunset, this memo described a method >> helping traffic migration to IPv6. With the growth of IPv6 traffic, >> operators could safely turn off IPv4 and evolve to IPv6-only network. >> In order to achieve the goal, new traffic-migration options have been >> proposed in DHCPv6 and PCP. IPv6 traffic steering could be performed >> using those configurations. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-chen-sunset4-traffic-migration >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-chen-sunset4-traffic-migration-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the > sender immediately and permanently delete the original and any copy of this > E-mail and any printout. > From marc.blanchet@viagenie.ca Wed Oct 24 12:11:32 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5374921F88F2 for ; Wed, 24 Oct 2012 12:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6x1if3u81g1 for ; Wed, 24 Oct 2012 12:11:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A96E221F88EB for ; Wed, 24 Oct 2012 12:11:31 -0700 (PDT) Received: from h114.viagenie.ca (h114.viagenie.ca [206.123.31.114]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 302DC412DC for ; Wed, 24 Oct 2012 15:11:31 -0400 (EDT) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_43B2784E-8686-426E-99F8-16E0656CBA84" Date: Wed, 24 Oct 2012 15:11:30 -0400 Message-Id: To: sunset4@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [sunset4] agenda v1.0 for IETF85 sunset4 meeting X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 19:11:32 -0000 --Apple-Mail=_43B2784E-8686-426E-99F8-16E0656CBA84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, please find the first version of the agenda for our IETF85 meeting. = Please send requests/modifications/... to the chairs = (sunset4-chairs@tools.ietf.org) Marc&Wes http://www.ietf.org/proceedings/85/agenda/agenda-85-sunset4 Sunset4 Working Group Meeting Agenda IETF 85, Atlanta, GA, USA November 2012 - Administrativia - New Charter revision =20 - Gap Analysis for IPv4 Sunset http://tools.ietf.org/id/draft-ietf-sunset4-gapanalysis - Turning off IPv4 Using DHCPv6 http://tools.ietf.org/id/draft-perreault-sunset4-noipv4 - Weakening Aggregated Traffic of DHCP Discover Messages http://tools.ietf.org/id/draft-yang-sunset4-weaken-dhcp - Graceful IPv4 Sunset with Traffic Migration http://tools.ietf.org/id/draft-chen-sunset4-traffic-migration - Managed Objects for Carrier Grade NAT (CGN) http://tools.ietf.org/id/draft-perreault-sunset4-cgn-mib - Stateless IPv4 Network Address Translation http://tools.ietf.org/id/draft-tsou-stateless-nat44 --Apple-Mail=_43B2784E-8686-426E-99F8-16E0656CBA84 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Hello,
 please find the first version of the agenda for our IETF85 meeting. Please send requests/modifications/... to the chairs (sunset4-chairs@tools.ietf.org)

Marc&Wes

http://www.ietf.org/proceedings/85/agenda/agenda-85-sunset4

Sunset4 Working Group Meeting Agenda
IETF 85, Atlanta, GA, USA
November 2012

- Administrativia

- New Charter revision  

- Gap Analysis for IPv4 Sunset
  http://tools.ietf.org/id/draft-ietf-sunset4-gapanalysis

- Turning off IPv4 Using DHCPv6
  http://tools.ietf.org/id/draft-perreault-sunset4-noipv4

- Weakening Aggregated Traffic of DHCP Discover Messages
  http://tools.ietf.org/id/draft-yang-sunset4-weaken-dhcp

- Graceful IPv4 Sunset with Traffic Migration
  http://tools.ietf.org/id/draft-chen-sunset4-traffic-migration

- Managed Objects for Carrier Grade NAT (CGN)
  http://tools.ietf.org/id/draft-perreault-sunset4-cgn-mib

- Stateless IPv4 Network Address Translation
  http://tools.ietf.org/id/draft-tsou-stateless-nat44

--Apple-Mail=_43B2784E-8686-426E-99F8-16E0656CBA84-- From Olaf.Bonness@telekom.de Thu Oct 25 06:08:33 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DB521F89D6 for ; Thu, 25 Oct 2012 06:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5v3V28SjxMs for ; Thu, 25 Oct 2012 06:08:32 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 42B6121F8869 for ; Thu, 25 Oct 2012 06:08:32 -0700 (PDT) Received: from he113598.emea1.cds.t-internal.com ([10.125.65.117]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 25 Oct 2012 15:08:30 +0200 Received: from HE113605.emea1.cds.t-internal.com ([169.254.1.124]) by HE113598.emea1.cds.t-internal.com ([2002:7cd:4175::7cd:4175]) with mapi; Thu, 25 Oct 2012 15:08:30 +0200 From: To: Date: Thu, 25 Oct 2012 15:08:29 +0200 Thread-Topic: [sunset4] On-Demand Provisioning of IPv4 Addresses Thread-Index: Ac2q1BDcddVTPfNNT4mmycXt1zKVewH1soow Message-ID: References: <507C0714.5070603@viagenie.ca> In-Reply-To: <507C0714.5070603@viagenie.ca> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sunset4@ietf.org Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 13:08:33 -0000 Hi Simon Nearly missed your email below. Just a few feedback to the problems 9-12 yo= u mentioned in I-D for sunset gap analysis: Problem 9: RFC6555 recommends a 150-250 ms timeout / head start for IPv6. A= ssuming that the E2E network connectivity for IPv6 is comparable to IPv4 th= en no IPv4 connection attempt will be started and no IPv4 traffic will be g= enerated. Hence I-D.fleischhauer can be applied since no IPv4 address has t= o be provisioned. Problem 10: What would be an example for such a permanent connectivity chec= k and what percentage of end systems is affected? If this connectivity chec= k is done from an end system in the home LAN to a system in the Internet (a= nd has to use IPv4) then I-D. Fleischhauer can clearly not become effective= for this customer. So what :) (I-D.fleischhauer does not assume that it wi= ll be effective for 100% of the customers from the beginning.) Problem 11: ACK. But this would mean massive configurationally adjustments = to these hosts. Problem 12: ACK. But is this (and also Problem 11) really a problem or only= a remark? So far my 2 cents. Kind regards Olaf=20 -----Urspr=FCngliche Nachricht----- Von: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] Im Auftrag = von Simon Perreault Gesendet: Montag, 15. Oktober 2012 14:53 An: sunset4@ietf.org Betreff: [sunset4] On-Demand Provisioning of IPv4 Addresses All, Cathy Zhou sent me the following addition to the IPv4 sunset gap analysis d= raft. Unless the WG disagrees, I will add it to the -01 revision (to be pub= lished before the IETF85 deadline). Please also feel free to comment on the technical issue itself. Thanks, Simon > 6. On-Demand Provisioning of IPv4 Addresses > > As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers > will become smaller. This could be exploited by an ISP to save IPv4 > addresses by provisioning them on-demand to subscribers and > reclaiming them when they are no longer used. This idea is described > in [I-D.fleischhauer-ipv4-addr-saving] and [BBF.TR242] for the > context of PPP sessions. In these scenarios, the home router is > responsible for requesting and releasing IPv4 addresses, based on > snooping the traffic generated by the hosts in the LAN, which are > still dual-stack and unaware that their traffic is being snooped. > > PROBLEM 9: Dual-stack hosts that implement Happy-Eyeballs [RFC6555] > will generate both IPv4 and IPv6 traffic even if the > algorithm end up chooosing IPv6. This means that an > IPv4 address will always be requested by the home > router, which defeats the purpose of on-demand > provisioning. > > PROBLEM 10: Many operating systems periodically perform some kind of > network connectivity check as long as an interface is > up. Similarly, applications often send keep-alive > traffic continuously. This permanent "background noise" > will prevent an IPv4 address from being released by the > home router. > > PROBLEM 11: Hosts in the LAN have no knowledge that IPv4 is > available to them on-demand only. If they had explicit > knowledge of this fact, they could tune their behaviour > so as to be more conservative in their use of IPv4. > > PROBLEM 12: This mechanism is only being proposed for PPP even > though it could apply to other provisioning protocols > (e.g., DHCP). -- 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 _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4 From simon.perreault@viagenie.ca Thu Oct 25 08:59:16 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B57321F8937 for ; Thu, 25 Oct 2012 08:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okcxqqAI8AT6 for ; Thu, 25 Oct 2012 08:59:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9F38B21F892D for ; Thu, 25 Oct 2012 08:59:15 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:3ce3:b168:5067:7d0d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ADD78400B4 for ; Thu, 25 Oct 2012 11:59:14 -0400 (EDT) Message-ID: <508961D2.6000006@viagenie.ca> Date: Thu, 25 Oct 2012 11:59:14 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: sunset4@ietf.org References: <507C0714.5070603@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:59:16 -0000 Le 2012-10-25 09:08, Olaf.Bonness@telekom.de a 閏rit : > Problem 9: RFC6555 recommends a 150-250 ms timeout / head start for > IPv6. Assuming that the E2E network connectivity for IPv6 is > comparable to IPv4 then no IPv4 connection attempt will be started > and no IPv4 traffic will be generated. Hence I-D.fleischhauer can be > applied since no IPv4 address has to be provisioned. Many connections take more than 120-250 ms to establish, even if IPv6 always ends up winning... It would be interesting to measure this. My instinct is that just casual browsing dual stack sites with happy eyeballs and an IPv6 head start would trigger IPv4 traffic within a minute or so. > Problem 10: What would be an example for such a permanent > connectivity check and what percentage of end systems is affected? If > this connectivity check is done from an end system in the home LAN to > a system in the Internet (and has to use IPv4) then I-D. Fleischhauer > can clearly not become effective for this customer. So what :) > (I-D.fleischhauer does not assume that it will be effective for 100% > of the customers from the beginning.) I think recent versions of Windows, Mac OS X, Android, iOS all do such connectivity checks when a network interface comes up. I think those tests include making an HTTP request to a server controlled by the vendor (i.e. Microsoft, Apple, Google). > Problem 11: ACK. But this would mean massive configurationally > adjustments to these hosts. Couldn't the home router tell the hosts using a standard protocol? Maybe even one designed by the IETF? ;) > Problem 12: ACK. But is this (and also Problem 11) really a problem > or only a remark? Let's say that this problem is straightforward to solve. ;) IMHO the real question is: is it worth solving? 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 wesley.george@twcable.com Thu Oct 25 09:53:47 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DBC21F8757 for ; Thu, 25 Oct 2012 09:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HcX+Gs-4Nqm for ; Thu, 25 Oct 2012 09:53:46 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id DE1A021F86B9 for ; Thu, 25 Oct 2012 09:53:45 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,648,1344225600"; d="scan'208";a="459325899" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Oct 2012 12:52:45 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 25 Oct 2012 12:53:21 -0400 From: "George, Wes" To: Simon Perreault , "sunset4@ietf.org" Date: Thu, 25 Oct 2012 12:53:21 -0400 Thread-Topic: [sunset4] On-Demand Provisioning of IPv4 Addresses Thread-Index: Ac2yybrPL6aaj80mQ8GqKMiEGqEm9QABVpXA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230336A8734F@PRVPEXVS15.corp.twcable.com> References: <507C0714.5070603@viagenie.ca> <508961D2.6000006@viagenie.ca> In-Reply-To: <508961D2.6000006@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:53:47 -0000 > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On > Behalf Of Simon Perreault > Sent: Thursday, October 25, 2012 11:59 AM > To: sunset4@ietf.org > Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses > > > > Problem 10: What would be an example for such a permanent connectivity > > check and what percentage of end systems is affected? If this > > connectivity check is done from an end system in the home LAN to a > > system in the Internet (and has to use IPv4) then I-D. Fleischhauer > > can clearly not become effective for this customer. So what :) > > (I-D.fleischhauer does not assume that it will be effective for 100% > > of the customers from the beginning.) > > I think recent versions of Windows, Mac OS X, Android, iOS all do such > connectivity checks when a network interface comes up. I think those > tests include making an HTTP request to a server controlled by the > vendor (i.e. Microsoft, Apple, Google). [WEG] Windows 7 (and I think vista IIRC) helpfully puts a little warning ic= on over the network icon in the taskbar to signify that a network connectio= n has "no internet access" but I don't know the specifics of how it is dete= rmining this. Implementations of this type should be relatively straightfor= ward to test to see if they complain of "no internet access" when placing t= hem on an IPv6-only but internet-connected network, or slap a sniffer upstr= eam to see what comes out of common OSes when no applications are driving n= etwork traffic. If they do complain or send IPv4-only traffic for connectiv= ity checks, that means one of two things- $vendor was not smart enough to u= se DNS, and hardcoded an IPv4 address in the test or more likely $vendor wa= s not smart enough to dual-stack its chosen test server (yet). I think is a= temporary problem, but one worth highlighting in a document like this sinc= e it does have the potential to disturb any attempt to do on-demand IPv4 pr= ovisioning. Rather than waving it off as acceptable losses, I'd call it out as a potent= ially significant gap that defeats this optimization, since it's relatively= easily fixed by the vendor. You could even discuss the alternative of locally spoofing such well-known = connectivity checks to intercept them before they force the router to enabl= e IPv4. Speaking just as an individual, Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Thu Oct 25 11:25:28 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D0421F88A7 for ; Thu, 25 Oct 2012 11:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.256 X-Spam-Level: X-Spam-Status: No, score=0.256 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk4HXJr1hBTL for ; Thu, 25 Oct 2012 11:25:27 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E34F621F848D for ; Thu, 25 Oct 2012 11:25:26 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,648,1344225600"; d="scan'208,217";a="459400674" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Oct 2012 14:24:31 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Thu, 25 Oct 2012 14:25:04 -0400 From: "George, Wes" To: "sunset4@ietf.org" Date: Thu, 25 Oct 2012 14:25:04 -0400 Thread-Topic: draft on DNS cache server selection IPv4/IPv6 Thread-Index: Ac2y3guOC4NsKxySRpu+Y9cCqEez8w== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230336A8751F@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD59230336A8751FPRVPEXVS15cor_" MIME-Version: 1.0 Cc: "draft-yasuda-cache-server-selection@tools.ietf.org" Subject: [sunset4] draft on DNS cache server selection IPv4/IPv6 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 18:25:28 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD59230336A8751FPRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I want to bring this draft to Sunset4's attention, as I think that there ar= e some things in here that we have been discussing as it relates to communi= cating the preference of IPv4 vs IPv6 to CPE or CE devices. The authors of = draft-kaliwoda and draft-chen should especially take notice, as I think the= re are opportunities to incorporate each other's ideas. http://tools.ietf.org/html/draft-yasuda-cache-server-selection-01 Thanks, Wes ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_2671C6CDFBB59E47B64C10B3E0BD59230336A8751FPRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I want to bring this draft to Sunset4’s attent= ion, as I think that there are some things in here that we have been discus= sing as it relates to communicating the preference of IPv4 vs IPv6 to CPE o= r CE devices. The authors of draft-kaliwoda and draft-chen should especially take notice, as I think there are opportu= nities to incorporate each other’s ideas.

http://tools.ietf.org/html/draft-yasuda-cache-ser= ver-selection-01

 

Thanks,

 

Wes

 


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_2671C6CDFBB59E47B64C10B3E0BD59230336A8751FPRVPEXVS15cor_-- From dwing@cisco.com Fri Oct 26 08:27:54 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B98F21F8651 for ; Fri, 26 Oct 2012 08:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.589 X-Spam-Level: X-Spam-Status: No, score=-110.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jy713AUsgnh for ; Fri, 26 Oct 2012 08:27:53 -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 B471021F8650 for ; Fri, 26 Oct 2012 08:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3064; q=dns/txt; s=iport; t=1351265273; x=1352474873; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=IIFK8CFAxq9H5zRYhgBAlvc9XM1ArbL5ZDlnyhyZYrE=; b=OoFbF5zUfXUWV42ArEnDafr+wTAiKkTqnagR4x6gNPf2KVg0xgS07pwa nUnAFvvyfQ2j9OgohyimZrLP3VqKlJ0MFUZmqzTJT3HCe6vDLPrHmkzLg hmATN8DUECtiurdUZV+mpwE5mIp6f6MGoNCUTiZ2IE/qHMzfljOvtjKed k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8KAH+rilCrRDoI/2dsb2JhbABEwTMDgQmBCIIeAQEBAwEIAggBcgEDAgkRBAEBKAcZLQMBBQgCBAESCwUSh14FDJ0joBqLcYEehVADiCQ1hRWIBYEXjTyBa4MP X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="62367062" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 26 Oct 2012 15:27:53 +0000 Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9QFRrog006061; Fri, 26 Oct 2012 15:27:53 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <507C0714.5070603@viagenie.ca> <508961D2.6000006@viagenie.ca> In-Reply-To: <508961D2.6000006@viagenie.ca> Date: Fri, 26 Oct 2012 08:27:52 -0700 Message-ID: <0c8c01cdb38e$773321a0$659964e0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFlm4xOKKBNlxwaKoUUUaqzidHLXgIQDSOTAipjV6aYehCpcA== Content-Language: en-us Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 15:27:54 -0000 > -----Original Message----- > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On > Behalf Of Simon Perreault > Sent: Thursday, October 25, 2012 8:59 AM > To: sunset4@ietf.org > Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses >=20 > Le 2012-10-25 09:08, Olaf.Bonness@telekom.de a =E9crit : > > Problem 9: RFC6555 recommends a 150-250 ms timeout / head start for > > IPv6. Assuming that the E2E network connectivity for IPv6 is > > comparable to IPv4 then no IPv4 connection attempt will be started = and > > no IPv4 traffic will be generated. Hence I-D.fleischhauer can be > > applied since no IPv4 address has to be provisioned. >=20 > Many connections take more than 120-250 ms to establish, even if IPv6 > always ends up winning... >=20 > It would be interesting to measure this. My instinct is that just = casual > browsing dual stack sites with happy eyeballs and an IPv6 head start > would trigger IPv4 traffic within a minute or so. >=20 > > Problem 10: What would be an example for such a permanent = connectivity > > check and what percentage of end systems is affected? If this > > connectivity check is done from an end system in the home LAN to a > > system in the Internet (and has to use IPv4) then I-D. Fleischhauer > > can clearly not become effective for this customer. So what :) > > (I-D.fleischhauer does not assume that it will be effective for 100% > > of the customers from the beginning.) >=20 > I think recent versions of Windows, Mac OS X, Android, iOS all do such > connectivity checks when a network interface comes up. I think those > tests include making an HTTP request to a server controlled by the > vendor (i.e. Microsoft, Apple, Google). Yes, for example Windows 7 (and I think Vista and 8) do this for IPv4, = http://blog.superuser.com/2011/05/16/windows-7-network-awareness/ and for IPv6, Windows 8 tries to connect to an IPv6-only server on the Internet, as described in http://blogs.msdn.com/b/b8/archive/2012/06/05/connecting-with-ipv6-in-win= dow s-8.aspx > > Problem 11: ACK. But this would mean massive configurationally > > adjustments to these hosts. >=20 > Couldn't the home router tell the hosts using a standard protocol? = Maybe > even one designed by the IETF? ;) >=20 > > Problem 12: ACK. But is this (and also Problem 11) really a problem = or > > only a remark? >=20 > Let's say that this problem is straightforward to solve. ;) IMHO the > real question is: is it worth solving? I don't see a significant enough advantage to solving the problem, especially considering the additional user-visible latency when the user does, in fact, need to use IPv4 (acquiring an IPv4 address at that time will take several hundred milliseconds). Also, the whole purpose of the scheme is to undersubscribe IPv4 addresses (that is, have fewer IPv4 addresses than necessary), which means there will be occasions where no IPv4 address is available -- which will cause customer support calls ("My Internet Is Down"). -d From Olaf.Bonness@telekom.de Fri Oct 26 09:00:26 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54A021F8634 for ; Fri, 26 Oct 2012 09:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLliXjQoo1ij for ; Fri, 26 Oct 2012 09:00:25 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id A147D21F8625 for ; Fri, 26 Oct 2012 09:00:24 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 26 Oct 2012 18:00:18 +0200 Received: from HE113605.emea1.cds.t-internal.com ([169.254.1.124]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%14]) with mapi; Fri, 26 Oct 2012 18:00:17 +0200 From: To: Date: Fri, 26 Oct 2012 18:00:16 +0200 Thread-Topic: [sunset4] On-Demand Provisioning of IPv4 Addresses Thread-Index: AQFlm4xOKKBNlxwaKoUUUaqzidHLXgIQDSOTAipjV6aYehCpcIAAA3lA Message-ID: References: <507C0714.5070603@viagenie.ca> <508961D2.6000006@viagenie.ca> <0c8c01cdb38e$773321a0$659964e0$@cisco.com> In-Reply-To: <0c8c01cdb38e$773321a0$659964e0$@cisco.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: simon.perreault@viagenie.ca, sunset4@ietf.org Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:00:27 -0000 Von: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] Im Auftrag = von Dan Wing Gesendet: Freitag, 26. Oktober 2012 17:28 An: 'Simon Perreault'; sunset4@ietf.org Betreff: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses --------- Snip -------------------------- Some lines removed --------- Snip -------------------------- I don't see a significant enough advantage to solving the problem, especial= ly considering the additional user-visible latency when the user does, in f= act, need to use IPv4 (acquiring an IPv4 address at that time will take sev= eral hundred milliseconds). Also, the whole purpose of the scheme is to un= dersubscribe IPv4 addresses (that is, have fewer IPv4 addresses than necess= ary), which means there will be occasions where no IPv4 address is availabl= e -- which will cause customer support calls ("My Internet Is Down"). -d [Obo]: I can see an advantage for this scheme as the I-D fleischhauer also = tries to sketch.=20 Regarding the additional user visible latency: Yes you are right, requestin= g an IPv4 address can take several 100 ms depending on the BRAS system and = how you do IPv4 address pool handling, Radius etc. (but we've also observed= delays between 100 and 200ms). This will delay the first IPv4 connection a= ttempt (and may at the end result in an incorrect preference of an IPv6 con= nection for this destination in terms of HE) but when the IPv4 address is p= rovided then the following connection attempts will follow the HE mechanism= as usual. The "My Internet Is Down" syndrome will also happen in today's IPv4 world w= hen the service provider has made a wrong decision regarding the size of it= s address pools or has done any other misconfiguration and is hence not spe= cific to the approach of I-D fleischhauer.=20 Besides right-sizing the IPv4 address pools according to the real needs, I-= D fleischhauer also allows to get rid of unused IPv4 addresses in Dual-Stac= k PPP sessions and could that's why be a needed IPv4 sun setting mechanism. Just my 2 cents.=09 Olaf _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4 From rjs@rob.sh Sat Oct 27 15:33:07 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9A821F844C for ; Sat, 27 Oct 2012 15:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5qsiztwgqqG for ; Sat, 27 Oct 2012 15:33:07 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 17A0721F8230 for ; Sat, 27 Oct 2012 15:33:03 -0700 (PDT) Received: from [93.97.180.64] (helo=lait.config) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1TSEte-00087M-Q6; Sat, 27 Oct 2012 23:30:26 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rob Shakir In-Reply-To: <0c8c01cdb38e$773321a0$659964e0$@cisco.com> Date: Sat, 27 Oct 2012 23:32:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6A699AA0-B07E-444C-9BFA-C942E514A0FD@rob.sh> References: <507C0714.5070603@viagenie.ca> <508961D2.6000006@viagenie.ca> <0c8c01cdb38e$773321a0$659964e0$@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1257) Cc: 'Simon Perreault' , sunset4@ietf.org Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 22:33:07 -0000 On 26 Oct 2012, at 16:27, Dan Wing wrote: >>> Problem 12: ACK. But is this (and also Problem 11) really a problem = or >>> only a remark? >>=20 >> Let's say that this problem is straightforward to solve. ;) IMHO the >> real question is: is it worth solving? >=20 > I don't see a significant enough advantage to solving the problem, > especially considering the additional user-visible latency when > the user does, in fact, need to use IPv4 (acquiring an IPv4 address > at that time will take several hundred milliseconds). Also, the > whole purpose of the scheme is to undersubscribe IPv4 addresses (that > is, have fewer IPv4 addresses than necessary), which means there > will be occasions where no IPv4 address is available -- which will > cause customer support calls ("My Internet Is Down"). I think that the problem described in PROBLEM 9 - 12 are valuable to = examine. A solution may require tweaks to the solution that is made in = the referenced draft and BBF TR-242. One observation is that the problem = of the delay in having an IPv4 address allocated might look similar to = those in other network environments, such as walk-by mobile users on = WiFi (i.e., these users are present, but not necessarily actually = sending traffic) but the pool of available addresses at a certain = hotspot is limited. In my view, in a deployment where there is subscriber growth, and a = finite set of addresses (which may be less than # of subscribers at some = point) that can be allocated, it would seem to be advantageous to "time = share" these addresses, based on the fact that users are not necessarily = all active simultaneously, and/or are not accessing IPv4 content = simultaneously. As with any statistical multiplexing model, there is a = risk that there will be insufficient resources based on a theoretical = demand, but accepting this risk is a calculated decision taken by a = network operator (akin to that of "do I build my core network to support = the theoretical peak of all customers simultaneously?"). I see an = advantage in having a mechanism such that an operator can accept this = risk, rather than concluding that the advantage of any change is "not = significant enough" to examine the problem. It would seem to me that the advantage is being able to balance the cost = of an alternate translation mechanism (e.g., some form of = NAT64/tunnelling with shared addressing etc., with the cost of this = infrastructure plus the complexity of holding state in an alternate = network device) against the cost of potential support calls. Cheers, r. From phdgang@gmail.com Sun Oct 28 03:17:56 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEE821F844D for ; Sun, 28 Oct 2012 03:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv-6l6PZHti7 for ; Sun, 28 Oct 2012 03:17:56 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 328E121F81FE for ; Sun, 28 Oct 2012 03:17:56 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4751296vbb.31 for ; Sun, 28 Oct 2012 03:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hEp+hhrEX10VFkGHfrLHZF+OjiDUzX6Bh+x7fM8inq0=; b=yNLp8z7pEwgSuAKBKVaFaMtfcD45kOEqx4YvutH3wN6NBuNzpvqy19CmyaAbn9hrev kIT9idxXtik7BVJxeV71J3SztivC39geq+ecsMgW3pPfIZ6EBAqeNzxsQEjgE9VdyJQy 9c+8xbnhIe9NPr0/fVUqToBzpOzAH17WH8qmImx6dTYzxuZ7wk2W7hI/e0pbirRFsSUx 5aCzT9hISPym7ytBr1508b86Jj1LGDmbyZ/1gYTVJPglgd9XeUSq5KedmM/As52j+r44 j5GNpWthK04H2JU0x8tVCG4N4ZZVIn9SpWhfC9xOKG8CII7kA1kwSlTGjbpAkMovIp+g Xnvw== MIME-Version: 1.0 Received: by 10.52.30.167 with SMTP id t7mr35588256vdh.56.1351419475635; Sun, 28 Oct 2012 03:17:55 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Sun, 28 Oct 2012 03:17:55 -0700 (PDT) In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230336A8751F@PRVPEXVS15.corp.twcable.com> References: <2671C6CDFBB59E47B64C10B3E0BD59230336A8751F@PRVPEXVS15.corp.twcable.com> Date: Sun, 28 Oct 2012 18:17:55 +0800 Message-ID: From: GangChen To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-yasuda-cache-server-selection@tools.ietf.org" , "sunset4@ietf.org" Subject: Re: [sunset4] draft on DNS cache server selection IPv4/IPv6 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 10:17:56 -0000 Hi George, Thanks for pointing us the link. I guess the issues have also been discussed in http://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-12. In regards to the solution, I may recommend draft-ietf-mif-dns-server-selection BRs Gang 2012/10/26, George, Wes : > I want to bring this draft to Sunset4's attention, as I think that there are > some things in here that we have been discussing as it relates to > communicating the preference of IPv4 vs IPv6 to CPE or CE devices. The > authors of draft-kaliwoda and draft-chen should especially take notice, as I > think there are opportunities to incorporate each other's ideas. > http://tools.ietf.org/html/draft-yasuda-cache-server-selection-01 > > Thanks, > > Wes > > > ________________________________ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the > sender immediately and permanently delete the original and any copy of this > E-mail and any printout. > From dwing@cisco.com Sun Oct 28 09:20:44 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2213921F86BA for ; Sun, 28 Oct 2012 09:20:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAqlzjoexc9e for ; Sun, 28 Oct 2012 09:20:43 -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 F36DD21F85D5 for ; Sun, 28 Oct 2012 09:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3319; q=dns/txt; s=iport; t=1351441242; x=1352650842; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=iW5cZjwdfNYzAQb+9lkAoLgqLzRs6249Db7t2KzUWu4=; b=dS/CHDJ5V9vTODzOIFiiewvpGNd7wR/1bVBUxExILDAIE0tjSMyFsU9M HmEnmx7w/4IjOmtG+mJGdUiFsu+VO2BcNNPEHOYWFw3cCwYiFvC01nFb+ l1llcohvH2K5zO7wTyL5+fBecHQscdTnFKpVIYfgQpQzNPvU6hef4+gvM M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOlZjVCrRDoH/2dsb2JhbABEwmCBCIIeAQEBAwEIAgQEAScrFAUHAQMCCQ4DBAEBAScHGS0JCAIEEwsFCweHXgWbUJ8gi3UBE4ZJA4hZhRWIBo5XgWuDD4E7CRc X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="59416549" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 28 Oct 2012 16:20:40 +0000 Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9SGKedB006994; Sun, 28 Oct 2012 16:20:40 GMT From: "Dan Wing" To: "'Rob Shakir'" References: <507C0714.5070603@viagenie.ca> <508961D2.6000006@viagenie.ca> <0c8c01cdb38e$773321a0$659964e0$@cisco.com> <6A699AA0-B07E-444C-9BFA-C942E514A0FD@rob.sh> In-Reply-To: <6A699AA0-B07E-444C-9BFA-C942E514A0FD@rob.sh> Date: Sun, 28 Oct 2012 09:20:40 -0700 Message-ID: <017801cdb528$2be79910$83b6cb30$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFlm4xOKKBNlxwaKoUUUaqzidHLXgIQDSOTAipjV6YBAg4GOQK4w2WImF9tyOA= Content-Language: en-us Cc: 'Simon Perreault' , sunset4@ietf.org Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 16:20:44 -0000 > -----Original Message----- > From: Rob Shakir [mailto:rjs@rob.sh] > Sent: Saturday, October 27, 2012 3:33 PM > To: Dan Wing > Cc: 'Simon Perreault'; sunset4@ietf.org > Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses > > > On 26 Oct 2012, at 16:27, Dan Wing wrote: > > >>> Problem 12: ACK. But is this (and also Problem 11) really a problem > >>> or only a remark? > >> > >> Let's say that this problem is straightforward to solve. ;) IMHO the > >> real question is: is it worth solving? > > > > I don't see a significant enough advantage to solving the problem, > > especially considering the additional user-visible latency when the > > user does, in fact, need to use IPv4 (acquiring an IPv4 address at > > that time will take several hundred milliseconds). Also, the whole > > purpose of the scheme is to undersubscribe IPv4 addresses (that is, > > have fewer IPv4 addresses than necessary), which means there will be > > occasions where no IPv4 address is available -- which will cause > > customer support calls ("My Internet Is Down"). > > I think that the problem described in PROBLEM 9 - 12 are valuable to > examine. A solution may require tweaks to the solution that is made in > the referenced draft and BBF TR-242. One observation is that the problem > of the delay in having an IPv4 address allocated might look similar to > those in other network environments, such as walk-by mobile users on > WiFi (i.e., these users are present, but not necessarily actually > sending traffic) but the pool of available addresses at a certain > hotspot is limited. > > In my view, in a deployment where there is subscriber growth, and a > finite set of addresses (which may be less than # of subscribers at some > point) that can be allocated, it would seem to be advantageous to "time > share" these addresses, based on the fact that users are not necessarily > all active simultaneously, and/or are not accessing IPv4 content > simultaneously. As with any statistical multiplexing model, there is a > risk that there will be insufficient resources based on a theoretical > demand, but accepting this risk is a calculated decision taken by a > network operator (akin to that of "do I build my core network to support > the theoretical peak of all customers simultaneously?"). They're not the same. Under-provisioning network bandwidth causes slowness for everyone, but everyone still gets (some) service. But under-provisioning IP addresses causes no service for some users. > I see an > advantage in having a mechanism such that an operator can accept this > risk, rather than concluding that the advantage of any change is "not > significant enough" to examine the problem. > > It would seem to me that the advantage is being able to balance the cost > of an alternate translation mechanism (e.g., some form of > NAT64/tunnelling with shared addressing etc., with the cost of this > infrastructure plus the complexity of holding state in an alternate > network device) against the cost of potential support calls. I would like to understand how MAP in Softwire does not meet that need. And perhaps MAP could provide the desired on-demand functionality by mapping all 65535 ports of an IPv4 address on demand. -d From rjs@rob.sh Mon Oct 29 11:55:51 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B0121F86DB for ; Mon, 29 Oct 2012 11:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAacqwXwnq8F for ; Mon, 29 Oct 2012 11:55:51 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC9521F86CD for ; Mon, 29 Oct 2012 11:55:51 -0700 (PDT) Received: from [217.41.236.135] (helo=[10.10.2.124]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1TSuSX-0002bI-H0; Mon, 29 Oct 2012 18:53:13 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <017801cdb528$2be79910$83b6cb30$@cisco.com> Date: Mon, 29 Oct 2012 18:55:46 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <507C0714.5070603@viagenie.ca> <508961D2.6000006@viagenie.ca> <0c8c01cdb38e$773321a0$659964e0$@cisco.com> <6A699AA0-B07E-444C-9BFA-C942E514A0FD@rob.sh> <017801cdb528$2be79910$83b6cb30$@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1257) Cc: 'Simon Perreault' , sunset4@ietf.org Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 18:55:51 -0000 Hi Dan, On 28 Oct 2012, at 16:20, Dan Wing wrote: >> I see an >> advantage in having a mechanism such that an operator can accept this >> risk, rather than concluding that the advantage of any change is "not >> significant enough" to examine the problem. >>=20 >> It would seem to me that the advantage is being able to balance the = cost >> of an alternate translation mechanism (e.g., some form of >> NAT64/tunnelling with shared addressing etc., with the cost of this >> infrastructure plus the complexity of holding state in an alternate >> network device) against the cost of potential support calls. >=20 > I would like to understand how MAP in Softwire does not meet that > need. =20 >=20 > And perhaps MAP could provide the desired on-demand functionality=20 > by mapping all 65535 ports of an IPv4 address on demand. I don't think that PROBLEM 9 - 11 are solely related to an = IPv4-on-demand solution as is described in the preceding paragraph in = the draft. Essentially, equally these problems could be applied to the = question of how one ensures MAP usage is minimised c.f. native IPv6.=20 In parallel, I do not think that we should immediately dismiss an = IPv4-on-demand solution such as the one proposed in = draft-fleischhauer-ipv4-addr-saving based on the fact that it re-uses a = large amount of existing operational concepts/understanding and existing = BRAS deployments. The deployment of MAP or other mechanisms requires new = operational concepts around multiple users being present on a single = IPv4 address, and deployment and understanding of MAP BR functions. =20 Cheers, r.= From dwing@cisco.com Mon Oct 29 12:01:23 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB08621F8743 for ; Mon, 29 Oct 2012 12:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CJ4RJ44fOHz for ; Mon, 29 Oct 2012 12:01:23 -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 26E8121F873E for ; Mon, 29 Oct 2012 12:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2016; q=dns/txt; s=iport; t=1351537283; x=1352746883; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=6h3y6L/aF2/JBwMnjzHNzWapUXsZSYlaKwIuSXm6pCY=; b=f/ESIHa4dwzKaaPGGUHJECpkVzicz9CLNoQBR73+EG8jf5wQkhauCl9/ /rxiyUiISXuJU7l1qvvlfxMrH3/KqWvpvsq0yUXg6xTtIoLOGIO7Zxk6n ER+B2UMDVPT2PYqg6KEWYKq7fMMEYbuMnYC2WNGcTVwX9HHgZv+rCxEdF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACXRjlCrRDoG/2dsb2JhbABEwwSBCIIeAQEBAwEIAgQEAScrFAUHAQMCCQ4DBAEBAScHGS0JCAIEEwsFCweHXgWcAp90i3WGXQOIWYUViAaOV4Frgw8 X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="59505908" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 29 Oct 2012 19:01:19 +0000 Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9TJ1JVs007866; Mon, 29 Oct 2012 19:01:19 GMT From: "Dan Wing" To: "'Rob Shakir'" References: <507C0714.5070603@viagenie.ca> <508961D2.6000006@viagenie.ca> <0c8c01cdb38e$773321a0$659964e0$@cisco.com> <6A699AA0-B07E-444C-9BFA-C942E514A0FD@rob.sh> <017801cdb528$2be79910$83b6cb30$@cisco.com> In-Reply-To: Date: Mon, 29 Oct 2012 12:01:19 -0700 Message-ID: <04ee01cdb607$c7edf720$57c9e560$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFlm4xOKKBNlxwaKoUUUaqzidHLXgIQDSOTAipjV6YBAg4GOQK4w2WIAdzU/GABrd6kqZhE2JEg Content-Language: en-us Cc: 'Simon Perreault' , sunset4@ietf.org Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 19:01:23 -0000 > -----Original Message----- > From: Rob Shakir [mailto:rjs@rob.sh] > Sent: Monday, October 29, 2012 11:56 AM > To: Dan Wing > Cc: 'Simon Perreault'; sunset4@ietf.org > Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses > > Hi Dan, > > On 28 Oct 2012, at 16:20, Dan Wing wrote: > >> I see an > >> advantage in having a mechanism such that an operator can accept this > >> risk, rather than concluding that the advantage of any change is "not > >> significant enough" to examine the problem. > >> > >> It would seem to me that the advantage is being able to balance the > >> cost of an alternate translation mechanism (e.g., some form of > >> NAT64/tunnelling with shared addressing etc., with the cost of this > >> infrastructure plus the complexity of holding state in an alternate > >> network device) against the cost of potential support calls. > > > > I would like to understand how MAP in Softwire does not meet that > > need. > > > > And perhaps MAP could provide the desired on-demand functionality by > > mapping all 65535 ports of an IPv4 address on demand. > > I don't think that PROBLEM 9 - 11 are solely related to an IPv4-on- > demand solution as is described in the preceding paragraph in the draft. > Essentially, equally these problems could be applied to the question of > how one ensures MAP usage is minimised c.f. native IPv6. > > In parallel, I do not think that we should immediately dismiss an IPv4- > on-demand solution such as the one proposed in draft-fleischhauer-ipv4- > addr-saving based on the fact that it re-uses a large amount of existing > operational concepts/understanding and existing BRAS deployments. The > deployment of MAP or other mechanisms requires new operational concepts > around multiple users being present on a single IPv4 address, and > deployment and understanding of MAP BR functions. I suggested we investigate MAP using all 65535 ports; there is no address sharing there. -d > Cheers, > r.= From wesley.george@twcable.com Wed Oct 31 06:14:34 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC11121F8674 for ; Wed, 31 Oct 2012 06:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilRvEddrO2GG for ; Wed, 31 Oct 2012 06:14:34 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A1F5621F8661 for ; Wed, 31 Oct 2012 06:14:33 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,687,1344225600"; d="scan'208";a="443446954" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 31 Oct 2012 09:14:01 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 31 Oct 2012 09:14:17 -0400 From: "George, Wes" To: Rob Shakir , Dan Wing Date: Wed, 31 Oct 2012 09:14:24 -0400 Thread-Topic: [sunset4] On-Demand Provisioning of IPv4 Addresses Thread-Index: Ac20kwyagIax0dyKQz+cvzrfkx9rjwC0kFqQ Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230336CAE893@PRVPEXVS15.corp.twcable.com> References: <507C0714.5070603@viagenie.ca> <508961D2.6000006@viagenie.ca> <0c8c01cdb38e$773321a0$659964e0$@cisco.com> <6A699AA0-B07E-444C-9BFA-C942E514A0FD@rob.sh> In-Reply-To: <6A699AA0-B07E-444C-9BFA-C942E514A0FD@rob.sh> 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: 'Simon Perreault' , "sunset4@ietf.org" Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 13:14:35 -0000 > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On > Behalf Of Rob Shakir > > On 26 Oct 2012, at 16:27, Dan Wing wrote: > > > > > I don't see a significant enough advantage to solving the problem, > > especially considering the additional user-visible latency when the > > user does, in fact, need to use IPv4 (acquiring an IPv4 address at > > that time will take several hundred milliseconds). Also, the whole > > purpose of the scheme is to undersubscribe IPv4 addresses (that is, > > have fewer IPv4 addresses than necessary), which means there will be > > occasions where no IPv4 address is available -- which will cause > > customer support calls ("My Internet Is Down"). [WEG] These are both valid concerns, but I do not believe those concerns tr= anslate to "don't look at this problem". Rather, I think these are things t= hat need to be well-discussed, along with potential solutions to mitigate o= r reduce the impact of these issues. For example, we do a disservice if we = don't note that any address-sharing as a means to conserve addresses only w= orks in limited circumstances, and absolutely requires a strong focus on mo= ving as many things away from using IPv4 as possible to reduce the load, or= possibly a carefully chosen subset of customers to apply it to. Discussing= that potential IPv4 address assignment on-demand delay is another part of = articulating the future world where IPv4 access is likely to be impaired in= any number of ways with varying degrees of unpleasantness. IMO, any ISP th= at believes that they aren't likely to see increased support calls using an= y IPv4 address extension technology, especially if they aren't combining it= with aggressive IPv6 deployment and push for content transition is in deni= al. We're better off noting it up front. > > I think that the problem described in PROBLEM 9 - 12 are valuable to > examine. A solution may require tweaks to the solution that is made in > the referenced draft and BBF TR-242. One observation is that the problem > of the delay in having an IPv4 address allocated might look similar to > those in other network environments, such as walk-by mobile users on > WiFi (i.e., these users are present, but not necessarily actually > sending traffic) but the pool of available addresses at a certain > hotspot is limited. [WEG] +1 - Much as with the rest of sunset4, this is about rethinking what = IPv4 access means going forward. Back when dinosaurs roamed the internet an= d everyone used modems, IPv4 access was on-demand, and programs were even b= uilt to manage that (eg a setting that says "don't request network access u= nless you detect an active PPP connection" to keep a program from firing up= the modem unattended). Same drill happened in wireless world, where turnin= g off the network access during periods of idle was both a battery conserva= tion/RF capacity conservation and address conservation mechanism. My previo= us employer didn't use NAT on wireless for years because it was able to poo= l addresses at a reasonable oversub rate. The change brought on by always-o= n wireline IPv4 connectivity bled over into wireless with smartphones, and = that stopped working, but I think there's an argument to be made that part = of shutting down IPv4 is being cognizant of the fact that it may not be "al= ways-on" and building your apps and infrastructure based on that updated as= sumption. Indeed that may be necessary even if the primary goal isn't IPv4 = address conservation as an intermediate step to turning IPv4 off completely= . > > In my view, in a deployment where there is subscriber growth, and a > finite set of addresses (which may be less than # of subscribers at some > point) that can be allocated, it would seem to be advantageous to "time > share" these addresses, based on the fact that users are not necessarily > all active simultaneously, and/or are not accessing IPv4 content > simultaneously. As with any statistical multiplexing model, there is a > risk that there will be insufficient resources based on a theoretical > demand, but accepting this risk is a calculated decision taken by a > network operator (akin to that of "do I build my core network to support > the theoretical peak of all customers simultaneously?"). I see an > advantage in having a mechanism such that an operator can accept this > risk, rather than concluding that the advantage of any change is "not > significant enough" to examine the problem. > > It would seem to me that the advantage is being able to balance the cost > of an alternate translation mechanism (e.g., some form of > NAT64/tunnelling with shared addressing etc., with the cost of this > infrastructure plus the complexity of holding state in an alternate > network device) against the cost of potential support calls. > [WEG] Again, +1. The statistical analysis you have to do here to determine = your oversub rate really has to do with IPv6 uptake in your particular netw= ork application - the more IPv6 you deploy and your users can use (because = their chosen content and devices are IPv6-capable) the more IPv4 oversub yo= u could do without causing significant breakage. There's a happy medium to = be found. Other alternatives to extend IPv4 addresses (NAT, etc) require eq= uipment deployment, which isn't cheap, and in some cases is only likely to = be useful for a single digit number of years, potentially for less time tha= n a standard depreciation cycle. So it may be attractive in some cases to h= ave alternatives that don't require that equipment deployment but are still= mindful of the continued need for IPv4 service. The previous comments were made as an individual, not as a chair. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.