From pkern@spike.0x539.de Mon Apr 1 04:53:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5468621F8908 for ; Mon, 1 Apr 2013 04:53:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dFtCfVFTpmH for ; Mon, 1 Apr 2013 04:53:06 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id AD55D21F8904 for ; Mon, 1 Apr 2013 04:53:06 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UMdIM-0002p8-83 for v6ops@ietf.org; Mon, 01 Apr 2013 13:53:02 +0200 Received: from p2003006b0d036c015db3591ba524e763.dip.t-dialin.net ([2003:6b:d03:6c01:5db3:591b:a524:e763] helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UMdIN-0001wG-FY for v6ops@ietf.org; Mon, 01 Apr 2013 13:53:03 +0200 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1UMdIM-0005pg-QZ for v6ops@ietf.org; Mon, 01 Apr 2013 13:53:02 +0200 Date: Mon, 1 Apr 2013 13:53:02 +0200 From: Philipp Kern To: v6ops@ietf.org Message-ID: <20130401115302.GA18772@spike.0x539.de> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <51425EB5.6040703@dougbarton.us> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <1363805194.86628.YahooMailNeo@web142505.mail.bf1.yahoo.com> <20130320185148.GA26639@spike.0x539.de> <20130330170859.GA25715@spike.0x539.de> <51572EDB.1080208@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <51572EDB.1080208@gmail.com> Organization: The Debian Project (http://www.debian.org) X-Debbugs-No-Ack: yes User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 11:53:07 -0000 On Sat, Mar 30, 2013 at 07:28:43PM +0100, Alexandru Petrescu wrote: > IPv6 ULA local verwenden (use): [unchecked] > Lokale IPv6-Adresse (ULA): fd46:8713:d5b8:0001::1') >=20 > By the suggested example algorithm in RFC4193, the overall length of > the 'random' part should be 48, which seems to be the case with the > example above. Indeed it's being regenerated whenever the box is ticked. Which has the funny effect that you don't actually get what's written there, but after you submit the form to enable it, you get a new ULA. And a new ULA is presented after you turned it off (i.e. one you'll never get because it will be regenerated upon activation next time). Kind regards Philipp Kern From Fred.L.Templin@boeing.com Mon Apr 1 08:00:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F7021F8AF0 for ; Mon, 1 Apr 2013 08:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdpuzGaGlLQD for ; Mon, 1 Apr 2013 08:00:33 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 2343321F81FF for ; Mon, 1 Apr 2013 08:00:32 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r31F13s3015395 for ; Mon, 1 Apr 2013 08:01:03 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r31F12YW015364 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 1 Apr 2013 08:01:02 -0700 Received: from XCH-BLV-301.nw.nos.boeing.com (130.247.25.213) by XCH-NWHT-04.nw.nos.boeing.com (130.247.64.250) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 1 Apr 2013 08:00:31 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.119]) by XCH-BLV-301.nw.nos.boeing.com ([169.254.1.18]) with mapi id 14.02.0328.011; Mon, 1 Apr 2013 08:00:31 -0700 From: "Templin, Fred L" To: Randy Bush , Brian E Carpenter Thread-Topic: [v6ops] Documentation Prefixes for ULA Thread-Index: AQHOLN/WcDdAwILAM0uCxMTQdnmtp5i+W0iAgAAHwoCAAxUVgA== Date: Mon, 1 Apr 2013 15:00:29 +0000 Message-ID: <2134F8430051B64F815C691A62D98318043571@XCH-BLV-504.nw.nos.boeing.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> <5156A0FB.1060603@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: IETF v6ops list Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:00:33 -0000 FWIW, I don't think we need to be overly worried about overlap of the proposed document prefix (fc00:2001:db8::/48) with prefixes that might occur in actual isolated networks. I use the prefix 2001:db8::/32 all the time when I set up isolated test networks, and the implementations I have been using treat the addresses the same as for any IPv6 GUA. It's just that that prefix should never be injected into the public routing system, i.e., the same as for fc00::/8. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Randy Bush > Sent: Saturday, March 30, 2013 1:51 AM > To: Brian E Carpenter > Cc: IETF v6ops list > Subject: Re: [v6ops] Documentation Prefixes for ULA >=20 > >> Since it has come up, is there any interest in moving forward some > >> from of ULA-C? > > I don't see why. Although it could be automated, there is a cost > > involved in any form of guaranteed uniqueness >=20 > we could have internet registry or registries keep track of assignments. > ;~> >=20 > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Mon Apr 1 08:44:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8134121F8C04 for ; Mon, 1 Apr 2013 08:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY18bON3aXfg for ; Mon, 1 Apr 2013 08:44:50 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 08B6C21F8BBD for ; Mon, 1 Apr 2013 08:44:49 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r31FineA008448 for ; Mon, 1 Apr 2013 08:44:49 -0700 Received: from XCH-PHX-212.sw.nos.boeing.com (xch-phx-212.sw.nos.boeing.com [130.247.25.141]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r31FimJX008445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 1 Apr 2013 08:44:48 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.119]) by XCH-PHX-212.sw.nos.boeing.com ([169.254.12.161]) with mapi id 14.02.0328.011; Mon, 1 Apr 2013 08:44:48 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Ray Hunter Thread-Topic: [v6ops] ULA discussion #BCP or Informational Thread-Index: AQHOLXstsuV/Ws4JwkuMOm+GDwezcpi/57gAgAChFICAAPss4A== Date: Mon, 1 Apr 2013 15:44:47 +0000 Message-ID: <2134F8430051B64F815C691A62D9831804360E@XCH-BLV-504.nw.nos.boeing.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> <5155E4FE.8060707@bogus.com> <51573A36.7070407@gmail.com> <5157EE8E.7070207@globis.net> <515875AD.6030408@gmail.com> In-Reply-To: <515875AD.6030408@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:44:50 -0000 > I am talking without tunnels. >=20 > One wouldnt want two vehicles nearby to go first through their VPN > Gateways in Enterprise. >=20 > > Suggest you check out: NHRP, SSL, GRE, IPSec tunnel mode ..... >=20 > Yes, and protocol Mobile IP. All lack optimal routes - all go through > anchor points, triangular routing, and multi-angular routing in case of > moving networks. IRON (and its component tunneling technologies AERO, SEAL and VET) support route optimization. Thanks - Fred fred.l.templin@boeing.com From ipepelnjak@gmail.com Mon Apr 1 09:37:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE911E80A5 for ; Mon, 1 Apr 2013 09:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brHC1caMnmVV for ; Mon, 1 Apr 2013 09:37:17 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 620C311E80A2 for ; Mon, 1 Apr 2013 09:37:17 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e50so1127971eek.2 for ; Mon, 01 Apr 2013 09:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=DmtpRFNVWlGe+HrRGQ5KmVF/9wA9Hl6+JOr0tdlw+zI=; b=06yjmob8H+AALxBlqz7Mk2yA5ijLz1ph7y7a+Vugm3NlcSo4AdGBiFcCgkOJ205Gd/ 2wGaUt6fYPsFPHDbsR8zh+2gEn+A2j0cOPtcha/kbrf+qmhqUvN1uzXEPh217LE5hlGJ IPI97ThRsCb17R7b8uPz1Q1Nty87PgzsR4oaNDfe0K0zPNe4mWxE/vXDQNnsZpnWFpxC Kg3kWJ5O2QhwoeNCL7MuyEsXHmNU1HoXvgwI38Eas0+qWjTVZVQaEAktJtd8/Ijj03HY KoWRA/kqYKCK31Ec60iXsnearabSHMItJYcHiSHFINRbN8K6Q1YNLaSH9zoCE1S3Tt0K 33GA== X-Received: by 10.15.111.202 with SMTP id cj50mr159426eeb.6.1364834236356; Mon, 01 Apr 2013 09:37:16 -0700 (PDT) Received: from PIPINB2009 (BSN-176-173-251.dial-up.dsl.siol.net. [95.176.173.251]) by mx.google.com with ESMTPS id q5sm21924236eeo.17.2013.04.01.09.37.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Apr 2013 09:37:15 -0700 (PDT) From: "Ivan Pepelnjak" To: "'Templin, Fred L'" , "'Randy Bush'" , "'Brian E Carpenter'" References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> <5156A0FB.1060603@gmail.com> <2134F8430051B64F815C691A62D98318043571@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318043571@XCH-BLV-504.nw.nos.boeing.com> Date: Mon, 1 Apr 2013 18:37:14 +0200 Message-ID: <008201ce2ef7$2b4c65f0$81e531d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOLN/WcDdAwILAM0uCxMTQdnmtp5i+W0iAgAAHwoCAAxUVgIAAHCjg Content-Language: sl Cc: 'IETF v6ops list' Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:37:18 -0000 This looks to me like "we need to agree on which subnet from 10/8 to use = in documentation" > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of > Templin, Fred L > Sent: Monday, April 01, 2013 5:00 PM > To: Randy Bush; Brian E Carpenter > Cc: IETF v6ops list > Subject: Re: [v6ops] Documentation Prefixes for ULA >=20 > FWIW, I don't think we need to be overly worried about overlap of the > proposed document prefix (fc00:2001:db8::/48) with prefixes that might > occur in actual isolated networks. I use the prefix > 2001:db8::/32 all the time when I set up isolated test networks, and = the > implementations I have been using treat the addresses the same as for = any > IPv6 GUA. It's just that that prefix should never be injected into the > public routing system, i.e., the same as for fc00::/8. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf > > Of Randy Bush > > Sent: Saturday, March 30, 2013 1:51 AM > > To: Brian E Carpenter > > Cc: IETF v6ops list > > Subject: Re: [v6ops] Documentation Prefixes for ULA > > > > >> Since it has come up, is there any interest in moving forward = some > > >> from of ULA-C? > > > I don't see why. Although it could be automated, there is a cost > > > involved in any form of guaranteed uniqueness > > > > we could have internet registry or registries keep track of = assignments. > > ;~> > > > > randy > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Mon Apr 1 10:02:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1980021E804C for ; Mon, 1 Apr 2013 10:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.334 X-Spam-Level: * X-Spam-Status: No, score=1.334 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmjlH0wOQr4c for ; Mon, 1 Apr 2013 10:02:30 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 16D1711E80AE for ; Mon, 1 Apr 2013 10:02:26 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6B2D0940142 for ; Mon, 1 Apr 2013 19:02:19 +0200 (CEST) Message-ID: <5159BD9A.3000305@gmail.com> Date: Mon, 01 Apr 2013 19:02:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> <5156A0FB.1060603@gmail.com> <2134F8430051B64F815C691A62D98318043571@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318043571@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130401-0, 01/04/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:02:31 -0000 Le 01/04/2013 17:00, Templin, Fred L a écrit : > FWIW, I don't think we need to be overly worried about overlap of the > proposed document prefix (fc00:2001:db8::/48) with prefixes that > might occur in actual isolated networks. Ok. > I use the prefix 2001:db8::/32 all the time when I set up isolated > test networks, and the implementations I have been using treat the > addresses the same as for any IPv6 GUA. It's just that that prefix > should never be injected into the public routing system, i.e., the > same as for fc00::/8. Fred. Also at where I do small isolated networks we often set up such small networks with 2001:db8::. It's very handy. However, I am not sure whether this is the right thing I do... Maybe the RFC says somewhere that the Documentation prefix is only to be put on paper? I dont know, maybe it doesnt. But, the worst, is that the act of doing so - set up now a small network with 2001:db8:: - is actually a commitment to renumber when I connect that small network to another small network (both disconnected from the Internet). I have seen so many such small networks, they all start with first subnet having 2001:db8:1::/64, second 2, and so on. Then there is also this "dead:beef", "face:booc" and so on. I think I've seen collisions for many. It's still small, so no important problem to talk about - these are small networks. This is just a comment. Alex > > Thanks - Fred fred.l.templin@boeing.com > >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Randy Bush Sent: >> Saturday, March 30, 2013 1:51 AM To: Brian E Carpenter Cc: IETF >> v6ops list Subject: Re: [v6ops] Documentation Prefixes for ULA >> >>>> Since it has come up, is there any interest in moving forward >>>> some from of ULA-C? >>> I don't see why. Although it could be automated, there is a cost >>> involved in any form of guaranteed uniqueness >> >> we could have internet registry or registries keep track of >> assignments. ;~> >> >> randy _______________________________________________ v6ops mailing >> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From iljitsch@muada.com Mon Apr 1 10:45:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED30E21E804A for ; Mon, 1 Apr 2013 10:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hs2lpVCIBHwB for ; Mon, 1 Apr 2013 10:45:32 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 2F76821F8E04 for ; Mon, 1 Apr 2013 10:45:32 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:4da5:2938:ecbd:68ad] ([IPv6:2001:470:1f0b:1289:4da5:2938:ecbd:68ad]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r31HeMnb007667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Apr 2013 19:40:23 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <5159BD9A.3000305@gmail.com> Date: Mon, 1 Apr 2013 19:45:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <80B5ED67-7280-4B92-B16A-3BBA5363171C@muada.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> <5156A0FB.1060603@gmail.com> <2134F8430051B64F815C691A62D98318043571@XCH-BLV-504.nw.nos.boeing.com> <5159BD9A.3000305@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:45:33 -0000 On 1 apr 2013, at 19:02, Alexandru Petrescu = wrote: >> I use the prefix 2001:db8::/32 all the time when I set up isolated >> test networks > Also at where I do small isolated networks we often set up such small = networks with 2001:db8::. It's very handy. Wouldn't using ULAs for this be even more handy? Iljitsch= From alexandru.petrescu@gmail.com Mon Apr 1 11:32:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0688E11E80AE for ; Mon, 1 Apr 2013 11:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.964 X-Spam-Level: * X-Spam-Status: No, score=1.964 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI6QH7leZxYv for ; Mon, 1 Apr 2013 11:32:12 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEDA21F8DFB for ; Mon, 1 Apr 2013 11:32:01 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 21634940281; Mon, 1 Apr 2013 20:31:55 +0200 (CEST) Message-ID: <5159D29B.5050400@gmail.com> Date: Mon, 01 Apr 2013 20:31:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> <5156A0FB.1060603@gmail.com> <2134F8430051B64F815C691A62D98318043571@XCH-BLV-504.nw.nos.boeing.com> <5159BD9A.3000305@gmail.com> <80B5ED67-7280-4B92-B16A-3BBA5363171C@muada.com> In-Reply-To: <80B5ED67-7280-4B92-B16A-3BBA5363171C@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130401-0, 01/04/2013), Outbound message X-Antivirus-Status: Clean Cc: v6ops@ietf.org Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:32:20 -0000 Le 01/04/2013 19:45, Iljitsch van Beijnum a écrit : > On 1 apr 2013, at 19:02, Alexandru Petrescu wrote: > >>> I use the prefix 2001:db8::/32 all the time when I set up isolated >>> test networks > >> Also at where I do small isolated networks we often set up such small networks with 2001:db8::. It's very handy. > > Wouldn't using ULAs for this be even more handy? It would! If only I had an implementation at hand that generated ULA prefixes... something like: # generate-ula --local eth0 fd00:3124:AFE3::/64, press CR for more, or Ctrol-D to quit. Alex > > Iljitsch > From brian.e.carpenter@gmail.com Tue Apr 2 06:48:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5497821F84A6 for ; Tue, 2 Apr 2013 06:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqvciOzz3h3g for ; Tue, 2 Apr 2013 06:48:13 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 714A721F8499 for ; Tue, 2 Apr 2013 06:48:13 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id n12so478882wgh.7 for ; Tue, 02 Apr 2013 06:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=K2FaEq97JRZgLDbJh2mAq5p2EgNoEbkj9qcjBBSWntQ=; b=vw5tIuieDkPGKickBgOmIcjwnpLg77cLSP6JsumeC5wtc1xELiSkRSjsSF6tsLTINe rX6UC3/VD5FDZoJNm1l1gtoIFN6ESn5rmh/gMKuoPXX30tqSrmA9pb0LowQUwXu9Z8R4 dh5xdIS7Xy7eaLFldum/6xAvj1rmRGGzSmtMaUY2rCjxcfZ7KspT4vxTueePB0l8AE2v 3s4sGoBIpUSQh9XRnVGUMfm9lmgEO1XuVnsC/im0nijUNND+yH8GTbpyRzHuEyoCFBXs FtMia5+yuX1YuQT1wvpdeYeOW4iUGPEDSkrPHIivmWgBli4YJIeDRvd05IeNxJIWq9+I ChGQ== X-Received: by 10.180.97.233 with SMTP id ed9mr15880584wib.32.1364910492271; Tue, 02 Apr 2013 06:48:12 -0700 (PDT) Received: from [128.232.110.174] (c174.al.cl.cam.ac.uk. [128.232.110.174]) by mx.google.com with ESMTPS id fv2sm2702179wib.6.2013.04.02.06.48.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 06:48:11 -0700 (PDT) Message-ID: <515AE19E.4050401@gmail.com> Date: Tue, 02 Apr 2013 14:48:14 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> <5156A0FB.1060603@gmail.com> <2134F8430051B64F815C691A62D98318043571@XCH-BLV-504.nw.nos.boeing.com> <5159BD9A.3000305@gmail.com> In-Reply-To: <5159BD9A.3000305@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:48:14 -0000 > Maybe the RFC says somewhere that the Documentation prefix is only to be > put on paper? I dont know, maybe it doesnt. The point is that IANA will never allocate the documentation prefixes, so they will never be routed, even if used for testing purposes. The same is true for the documentation domains like example.com. But this argument doesn't apply to ULAs (or RFC 1918s) since they will never be routed. Also, the ID checklist (http://www.ietf.org/id-info/checklist.html) says: "Private addresses that would be used in the real world SHOULD be avoided in examples." iirc, it's a SHOULD precisely because sometimes it's essential to give RFC 1918 or ULA examples. I think my conclusion is that we don't need to do anything. Brian From cb.list6@gmail.com Tue Apr 2 06:53:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0167D21F87E4 for ; Tue, 2 Apr 2013 06:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSZ+4dE0uCf4 for ; Tue, 2 Apr 2013 06:53:33 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 47C5421F87D0 for ; Tue, 2 Apr 2013 06:53:33 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hj8so454668wib.8 for ; Tue, 02 Apr 2013 06:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Xgb19jDer8L3HZGnMEsSM1rCnudOHPAmxjGiLUnNhA8=; b=YiqSSVrF9KfBzkUjapS4qOr1h59/RBWGBINO8kOmqAQIiruYpt3QPJICqpNFIBY20e QzpN2qxvQXKGK0DfuPDMRg4HrG5Wy8bSvaKfavi5zpu5+Jd1va8iteCjvCCk95YyBWKU FWRyYOQTFkup0BM3cleFRQP6hi5Uq3w9FutVNg4QNjNgIv8lXtg3u8/Yo2fivPu8GqPC UlOVe1oCgTmS9xSovavdTKGvFTLvTtbfx7Xi5UtuiQOeUevi3L6ofjub3Zq6KN5pJWQr aQ7zQxyhQrOH9nsjvCHYMcOzcHz4Fm5M7fBxy1LiS6iMfA73tOD4f0wnZGZT/2StkOPj FYEQ== MIME-Version: 1.0 X-Received: by 10.194.20.40 with SMTP id k8mr22183085wje.16.1364910812256; Tue, 02 Apr 2013 06:53:32 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Tue, 2 Apr 2013 06:53:32 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Tue, 2 Apr 2013 06:53:32 -0700 (PDT) In-Reply-To: <515AE19E.4050401@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> <5156A0FB.1060603@gmail.com> <2134F8430051B64F815C691A62D98318043571@XCH-BLV-504.nw.nos.boeing.com> <5159BD9A.3000305@gmail.com> <515AE19E.4050401@gmail.com> Date: Tue, 2 Apr 2013 06:53:32 -0700 Message-ID: From: "cb.list6" To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b5d44041d626604d96110a6 Cc: IPv6 Operations Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:53:34 -0000 --047d7b5d44041d626604d96110a6 Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Apr 2, 2013 6:48 AM, "Brian E Carpenter" wrote: > > > Maybe the RFC says somewhere that the Documentation prefix is only to be > > put on paper? I dont know, maybe it doesnt. > > The point is that IANA will never allocate the documentation prefixes, > so they will never be routed, even if used for testing purposes. > The same is true for the documentation domains like example.com. > > But this argument doesn't apply to ULAs (or RFC 1918s) since they will > never be routed. > > Also, the ID checklist (http://www.ietf.org/id-info/checklist.html) > says: "Private addresses that would be used in the real world SHOULD > be avoided in examples." iirc, it's a SHOULD precisely because sometimes > it's essential to give RFC 1918 or ULA examples. > > I think my conclusion is that we don't need to do anything. > > Brian > +1. No need for ULA doc prefix. Random numbers are random and large numbers are large. CB > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --047d7b5d44041d626604d96110a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Apr 2, 2013 6:48 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
> > Maybe the RFC says somewhere that the Documentation prefix is onl= y to be
> > put on paper? =A0I dont know, maybe it doesnt.
>
> The point is that IANA will never allocate the documentation prefixes,=
> so they will never be routed, even if used for testing purposes.
> The same is true for the documentation domains like example.com.
>
> But this argument doesn't apply to ULAs (or RFC 1918s) since they = will
> never be routed.
>
> Also, the ID checklist (http://www.ietf.org/id-info/checklist.html)
> says: "Private addresses that would be used in the real world SHO= ULD
> be avoided in examples." iirc, it's a SHOULD precisely becaus= e sometimes
> it's essential to give RFC 1918 or ULA examples.
>
> I think my conclusion is that we don't need to do anything.
>
> =A0 =A0 Brian
>

+1. No need for ULA doc prefix.

Random numbers are random and large numbers are large.

CB

>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--047d7b5d44041d626604d96110a6-- From alexandru.petrescu@gmail.com Tue Apr 2 07:35:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B9D21F8A7B for ; Tue, 2 Apr 2013 07:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFP-PhzQW1-W for ; Tue, 2 Apr 2013 07:35:39 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 13A6D21F8A85 for ; Tue, 2 Apr 2013 07:35:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r32EZRPd025617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Apr 2013 16:35:27 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r32EZRhW020995; Tue, 2 Apr 2013 16:35:27 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r32EZNlA013049; Tue, 2 Apr 2013 16:35:27 +0200 Message-ID: <515AEC68.6050903@gmail.com> Date: Tue, 02 Apr 2013 16:34:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian E Carpenter References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> <5156A0FB.1060603@gmail.com> <2134F8430051B64F815C691A62D98318043571@XCH-BLV-504.nw.nos.boeing.com> <5159BD9A.3000305@gmail.com> <515AE19E.4050401@gmail.com> In-Reply-To: <515AE19E.4050401@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:35:40 -0000 Le 02/04/2013 15:48, Brian E Carpenter a écrit : >> Maybe the RFC says somewhere that the Documentation prefix is only to be >> put on paper? I dont know, maybe it doesnt. > > The point is that IANA will never allocate the documentation prefixes, > so they will never be routed, even if used for testing purposes. > The same is true for the documentation domains like example.com. > > But this argument doesn't apply to ULAs (or RFC 1918s) since they will > never be routed. > > Also, the ID checklist (http://www.ietf.org/id-info/checklist.html) > says: "Private addresses that would be used in the real world SHOULD > be avoided in examples." iirc, it's a SHOULD precisely because sometimes > it's essential to give RFC 1918 or ULA examples. > > I think my conclusion is that we don't need to do anything. In a sense I could agree towards not reserving 'documentation' ULA because it would risk loss of some address space. The explanation effort about ULAs is there simply to help continuing the convenience of using them. Alex > > Brian > > > > From alexandru.petrescu@gmail.com Tue Apr 2 07:48:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C95D21F85FC for ; Tue, 2 Apr 2013 07:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH+JLnPoLNQ9 for ; Tue, 2 Apr 2013 07:48:49 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id CA66F21F86A6 for ; Tue, 2 Apr 2013 07:48:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r32EmYuu028108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Apr 2013 16:48:34 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r32EmXIR027125; Tue, 2 Apr 2013 16:48:33 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r32EmT6W022408; Tue, 2 Apr 2013 16:48:33 +0200 Message-ID: <515AEF7A.9060505@gmail.com> Date: Tue, 02 Apr 2013 16:47:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> <513E3FA8.30002@bogus.com> <513E42C9.2050802@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F7@SRVHKE02.rdm.cz> <513E6E00.5000403@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141A01@SRVHKE02.rdm.cz> <513EA353.7020708@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141A05@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6DA141A05@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:48:50 -0000 Hello Ales, Sorry for late reply. YEs. This is right. The 3GPP specs there make think that the UE may request several prefixes with DHCPv6 Prefix Delegation. This is new to me. What remains to be seen is how this UE uses these requested prefixes (in addition to the use of the default /64 prefix). I don't think I see anything in the referred specs about how UE uses these prefixes. This email to say that the 64share document is right how it is now (assumes DHCPv6-PD in the future, and now just do this method). Alex Le 12/03/2013 04:50, Vízdal Ale¹ a écrit : > Hi Alex, > > let's start with TS 29.061 version 10.0.0, Section 11.2.1.3.5 IPv6 > Prefix Delegation via DHCPv6 that includes further references. > (http://www.3gpp.org/ftp/Specs/archive/29_series/29.061/29061-a00.zip) > > Cheers, Ales > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Monday, March 11, 2013 >> 11:39 PM To: Vízdal Ale¹ Cc: joel jaeggli; v6ops@ietf.org Subject: >> Re: [v6ops] Mic comments on link model in >> draft-ietf-v6ops-64share-03 >> >> Le 12/03/2013 00:55, Vízdal Ale¹ a écrit : >>>>> The 3GPP Rel-10 has introduced DHCP-PD. What's the problem >>>>> here? >>>> >>>> As far as I can remember, that is a PD for something in the >>>> core, the delegated prefix is for the UE to use on its cellular >>>> (not for the UE to use on its WLAN). >>>> >>>> Were that 3GPP use of DHCPv6-PD to be for a prefix on the UEs >>>> WLAN then... >>>> >>>> Or am I wrong about this? >>> >>> You seem to be wrong here as the PD is intended for an UE to >>> delegate a prefix to a >> LAN. >> >> Please point me to the 3GPP ref? >> >> (last time I checked it was a prefix for the UE on its 3GPP link) >> >> Alex >> >>> >>>> Alex >>> >>> Ales >>> >>> >> > > > From alexandru.petrescu@gmail.com Tue Apr 2 07:55:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC67F21F8A7B for ; Tue, 2 Apr 2013 07:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.874 X-Spam-Level: X-Spam-Status: No, score=-9.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCvlkDAsDdkB for ; Tue, 2 Apr 2013 07:55:09 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7882021F8A68 for ; Tue, 2 Apr 2013 07:55:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r32Et7hd002475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Apr 2013 16:55:07 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r32Et7Ac029793 for ; Tue, 2 Apr 2013 16:55:07 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r32Et3HW026547 for ; Tue, 2 Apr 2013 16:55:07 +0200 Message-ID: <515AF104.7030005@gmail.com> Date: Tue, 02 Apr 2013 16:53:56 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <513F18FF.2060700@gmail.com> <513F8F69.2050204@gmail.com> In-Reply-To: <513F8F69.2050204@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:55:10 -0000 Le 12/03/2013 21:26, Alexandru Petrescu a écrit : > Le 12/03/2013 19:29, Dmitry Anipko a écrit : [...] >> The draft currently says " The gateway routes the entire /64 to >> the UE and does not perform ND or Network Unreachability Detection >> (NUD) [RFC4861].". If you think this is not sufficient, do you want >> to suggest the particular text you'd like to see? > > Yes, I will, soon, thanks for asking. I will send something soon. After re-reading the discussion on v6ops I think I no longer need to provide any new text to 64share document. Thanks to all who discussed. The detail about the conditions about where 64share is disadvantageous are the following: - it provides only one /64 prefix to the LAN, if the device receives only one address on the cellular link. - some hacks on some USB dongles to which 64share is a competitor send NS and make 64share not work. But that's not a problem because it's not the right way for these USB dongles to do. In some past RFC I provided a counter-example corner case where a particular protocol wouldn't work. But that didnt serve anything in the subsequent years (neither did it block nor did it help advance - it was just useless.) Alex > > Basically that text is incomplete. It says it 'routes' but it > doesnt say how. Or here we have a fundamental distinctions for the > how; these boil down to what does the routing table entry at the > Gateway towards the UE looks like: is there a nexthop, is there a > device name, is the dev a ptp or a MAC-adressed link, etc. It's > because of the particular mixture of these parameters that 64share > mechanism works. Were it for the Gateway to have a different > mixture, 64share wouldnt work. > > Also, the part which says that "the Gateway does not perform ND on > that link" is very strange, because RFCs require ND on all interfaces > IIRC. Also, this is a router and should not accept RAs. > > Alex > >> >> Thank you. >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, March 12, >> 2013 5:01 AM To: Dmitry Anipko Cc: Gert Doering; v6ops@ietf.org >> Subject: Re: [v6ops] Mic comments on link model in >> draft-ietf-v6ops-64share-03 >> >> Le 12/03/2013 00:29, Dmitry Anipko a écrit : >>> Alexandru, >>> >>>>> Were the 3GPP links to have right MAC layers (non kludgy) >>>>> then maybe DHCPv6-PD were used instead of 64share. >>> >>> The actual point is that wherever DHCP-PD is available, it >>> should be used instead of /64share. Not just where there is a >>> "right" MAC layer. So there seems to be a violent agreement about >>> the long term direction and that it will cover the wider >>> scenarios. >> >> YEs, the long term intention is right. I agree in the long term >> one should use DHCPv6-PD to get a prefix for the WLAN of the UE >> connected on LTE. >> >> The only minor comment here is that I think (just suppose), from >> my recollection, that 3GPP specs need some clarification about >> this DHCPv6-PD use. >> >>> /64share is not the long term direction - it is a short/mid-term >>> fix. The draft says that, and in my opinion, it doesn't need >>> changes in this respect, because it is intentionally scoped to be >>> a short/mid-term fix for particular types of scenarios. >> >> Yes, right. It does not need to stress it is a midterm solution. >> It is already said. >> >> On another hand, for each one of the 3 scenarios, if 64share >> receives a NS from the network about the IPv6 address within the >> /64 - it will break. >> >> Alex >> >>> >>> -----Original Message----- From: v6ops-bounces@ietf.org >>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>> Sent: Monday, March 11, 2013 3:59 PM To: Gert Doering Cc: >>> v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model >>> in draft-ietf-v6ops-64share-03 >>> >>> Le 11/03/2013 22:53, Gert Doering a écrit : >>>> Hi, >>>> >>>> On Mon, Mar 11, 2013 at 09:32:15PM +0100, Alexandru Petrescu >>>> wrote: >>>>> Le 11/03/2013 19:58, Mikael Abrahamsson a écrit : >>>>>> On Mon, 11 Mar 2013, Alexandru Petrescu wrote: >>>>>> >>>>>>> We are already the knees deep into thingies. The IPv6 >>>>>>> stack (the one which uses IPv6 addresses, ND, routes, >>>>>>> interfaces - as 64share requires) is faced to these >>>>>>> thingies. >>>>>> >>>>>> The USB dongle does this magic in order to emulate a MAC >>>>>> layer towards the OS. It doesn't need to do this, but >>>>>> that's one way of doing it. >>>>> >>>>> This is a kind effort from the USB key - it helps a lot the >>>>> IPv6 stack. The stack sees the 3GPP interface just like any >>>>> other Ethernet interface. The stack does not need to do >>>>> wacky things like NO_ARP. >>>> >>>> I'm not sure why you think that this is helpful or kind - it >>>> just complicates things, while PPP interfaces have been around >>>> and well- understood for over 20 years >>> >>> PPP on cellular 3GPP links have failed to evolve for some >>> strange reason. (many other links have moved away from this ppp >>> nature). >>> >>> When a new kind of link shows up it first gets seen by IPv6 >>> stack as a serial, or as a ptp link. Then it slowly evolves to >>> IEEE, MAC addressable, multicast capable links. Now 3GPP links >>> try the same... >>> >>>> - no need for a MAC layer, extra overhead, "smart" firmware >>>> breaking stuff (like "packets coming from the wrong link-layer >>>> address" as necessary consequence of EUI-64 not giving the >>>> computer the link-local address that the network is expecting, >>>> etc.) >>> >>> Strange, the absence of a proper MAC layer is what allows >>> 64share to work... >>> >>> (no doubt DHCPv6 is not deployed on these MAC-less links, >>> because DHCPv6, like IPv6 ND, rely a lot on having a good MAC >>> layer). >>> >>>>> This is the future of 3GPP interfaces (as opposed to old ptp >>>>> addressless links). >>>> >>>> I hope not. It's a kludge. >>> >>> It may be implemented as what looks like kludgy patch, but it >>> may improve in the future. We should let space for that. >>> >>> It may turn in circles, but the first thing this 64share draft >>> says is that DHCPv6-PD is the right thing to do. And DHCPv6-PD >>> is working better on links which have MAC layers (e.g. during >>> the mulitcast SErver discovery phase one better has a multicast >>> feature built-in). Were the 3GPP links to have right MAC layers >>> (non kludgy) then maybe DHCPv6-PD were used instead of 64share. >>> >>>>> It's not only me who thinks so. Why would manufacturers of >>>>> 3GPP USB keys go through the effort to ask IEEE for >>>>> Organization IDs, if it were not for a belief in a technical >>>>> advantage of using MAC addresses on 3GPP links. >>>> >>>> "It makes windows drivers easier". Yay. >>> >>> Recent linux kernel efforst try to work in the same way as >>> windows ndis drivers do with recent USB LTE keys. >>> >>> Alex >>> >>>> >>>> Gert Doering -- NetMaster >>>> >>> >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From ales.vizdal@t-mobile.cz Tue Apr 2 08:28:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958B521F85E0 for ; Tue, 2 Apr 2013 08:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwbfKJVwdNEq for ; Tue, 2 Apr 2013 08:28:23 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4D721F85CB for ; Tue, 2 Apr 2013 08:28:21 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id 4D6D62E06F2; Tue, 2 Apr 2013 17:27:57 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk504.rdm.cz ([fe80::506:b9a6:d353:9494%12]) with mapi; Tue, 2 Apr 2013 17:28:15 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu Date: Tue, 2 Apr 2013 17:26:37 +0200 Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: Ac4vsaHBGRM+B18PSgimlPMhb4eSqwAAzmCg Message-ID: <1808340F7EC362469DDFFB112B37E2FCC74B81ACD1@SRVHKE02.rdm.cz> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> <513E3FA8.30002@bogus.com> <513E42C9.2050802@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F7@SRVHKE02.rdm.cz> <513E6E00.5000403@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141A01@SRVHKE02.rdm.cz> <513EA353.7020708@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141A05@SRVHKE02.rdm.cz> <515AEF7A.9060505@gmail.com> In-Reply-To: <515AEF7A.9060505@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:28:23 -0000 Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, April 02, 2013 4:47 PM > To: V=EDzdal Ale=B9 > Cc: joel jaeggli; v6ops@ietf.org > Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64sha= re-03 >=20 > Hello Ales, >=20 > Sorry for late reply. No worries, watching the ietf lists is a full time job ... ;-) > YEs. This is right. The 3GPP specs there make think that the UE may > request several prefixes with DHCPv6 Prefix Delegation. This is new to m= e. Well, it may request several prefixes, but there is still a limitation that= all prefixes=20 assigned to an UE must be aggregatable, so it will most likely get only one= prefix delegated. > What remains to be seen is how this UE uses these requested prefixes (in > addition to the use of the default /64 prefix). I don't think I see > anything in the referred specs about how UE uses these prefixes. It should use it to number its ip interfaces and it may delegate prefixes f= urther down the LAN in case it acts as the delegating router. > This email to say that the 64share document is right how it is now > (assumes DHCPv6-PD in the future, and now just do this method). >=20 > Alex Cheers, Ales From alexandru.petrescu@gmail.com Tue Apr 2 11:25:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D0521F8C85 for ; Tue, 2 Apr 2013 11:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.185 X-Spam-Level: X-Spam-Status: No, score=-10.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XId7EX7WbP9T for ; Tue, 2 Apr 2013 11:25:11 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C56D021F8C78 for ; Tue, 2 Apr 2013 11:25:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r32IOUPI012643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Apr 2013 20:24:30 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r32IOUa8014056; Tue, 2 Apr 2013 20:24:30 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r32ION2h011239; Tue, 2 Apr 2013 20:24:29 +0200 Message-ID: <515B2214.2060607@gmail.com> Date: Tue, 02 Apr 2013 20:23:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Templin, Fred L" References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> <5155E4FE.8060707@bogus.com> <51573A36.7070407@gmail.com> <5157EE8E.7070207@globis.net> <515875AD.6030408@gmail.com> <2134F8430051B64F815C691A62D9831804360E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831804360E@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:25:11 -0000 Le 01/04/2013 17:44, Templin, Fred L a écrit : >> I am talking without tunnels. >> >> One wouldnt want two vehicles nearby to go first through their VPN >> Gateways in Enterprise. >> >>> Suggest you check out: NHRP, SSL, GRE, IPSec tunnel mode ..... >> >> Yes, and protocol Mobile IP. All lack optimal routes - all go through >> anchor points, triangular routing, and multi-angular routing in case of >> moving networks. > > IRON (and its component tunneling technologies AERO, SEAL and VET) > support route optimization. That is good to know. We could discuss that if there is interest. There are a number of other draft proposals about this as well. And 2 RFCs with problem statement and analysis of solution space. Alex > > Thanks - Fred > fred.l.templin@boeing.com > > From wwwrun@rfc-editor.org Tue Apr 2 17:36:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361AA21F888B; Tue, 2 Apr 2013 17:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.914 X-Spam-Level: X-Spam-Status: No, score=-101.914 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8xylZ1LOmyE; Tue, 2 Apr 2013 17:36:50 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5D121F8881; Tue, 2 Apr 2013 17:36:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C2FEBB1E003; Tue, 2 Apr 2013 17:36:34 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130403003634.C2FEBB1E003@rfc-editor.org> Date: Tue, 2 Apr 2013 17:36:34 -0700 (PDT) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6877 on 464XLAT: Combination of Stateful and Stateless Translation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 00:36:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6877 Title: 464XLAT: Combination of Stateful and Stateless Translation Author: M. Mawatari, M. Kawashima, C. Byrne Status: Informational Stream: IETF Date: April 2013 Mailbox: mawatari@jpix.ad.jp, kawashimam@vx.jp.nec.com, cameron.byrne@t-mobile.com Pages: 14 Characters: 31382 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-464xlat-10.txt URL: http://www.rfc-editor.org/rfc/rfc6877.txt This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From iljitsch@muada.com Thu Apr 4 00:23:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC46921F85C6 for ; Thu, 4 Apr 2013 00:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDTgYdQ0JcwG for ; Thu, 4 Apr 2013 00:23:28 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 1129D21F852A for ; Thu, 4 Apr 2013 00:23:27 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r347IGkm037223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Apr 2013 09:18:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum Date: Thu, 4 Apr 2013 09:23:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130404071949.24400.75873.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1499) Cc: "draft-steffann-tunnels@tools.ietf.org" Subject: [v6ops] draft-steffann-tunnels-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 07:23:28 -0000 Hi all, We've submitted version-03 of our tunneling overview draft. We added a = discussion of SEAL and made changes to the security considerations. Iljitsch Begin forwarded message: > Title : A Comparison of IPv6 over IPv4 Tunnel = Mechanisms > Author(s) : S.J.M. Steffann > Iljitsch van Beijnum > Rick van Rein > Filename : draft-steffann-tunnels-03.txt > Pages : 39 > Date : 2013-04-04 > Abstract: > This document provides an overview of various ways to tunnel IPv6 > packets over IPv4 networks. It covers mechanisms in current use, > touches on several mechanisms that are now only of historic = interest, > and discusses some newer tunnel mechanisms that are not (yet) widely > used at the time of publication. The goal of the document is = helping > people with an IPv6-in-IPv4 tunneling need to select the mechanisms > that may apply to them. > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-steffann-tunnels > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-steffann-tunnels-03 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-steffann-tunnels-03 From holger.metschulat@telekom.de Thu Apr 4 01:29:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8CC21F93FC for ; Thu, 4 Apr 2013 01:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY4HwsxAjKSm for ; Thu, 4 Apr 2013 01:29:47 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2F721F9420 for ; Thu, 4 Apr 2013 01:29:46 -0700 (PDT) From: Received: from he111493.emea1.cds.t-internal.com ([10.206.92.96]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 04 Apr 2013 10:29:44 +0200 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE111493.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 4 Apr 2013 10:29:44 +0200 To: Date: Thu, 4 Apr 2013 10:29:43 +0200 Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: Ac4vsT790mw1VuhcQqy2yURKQGwQqQBXLnKw Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> <513E3FA8.30002@bogus.com> <513E42C9.2050802@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F7@SRVHKE02.rdm.cz> <513E6E00.5000403@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141A01@SRVHKE02.rdm.cz> <513EA353.7020708@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141A05@SRVHKE02.rdm.cz> <515AEF7A.9060505@gmail.com> In-Reply-To: <515AEF7A.9060505@gmail.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-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 08:29:48 -0000 Hi all, Prefix delegation should be used if the UE has more interfaces than just th= e 3GPP interfaces, and Internet access via the 3GPP interfaces should be sh= ared to the other interfaces (e.g. WLAN, wired, Bluetooth) so that the devi= ces connected to these interfaces can use the 3GPP uplink. This is specified in RFC3769 (PE/Aggregating Device/Delegating Router=3DGGS= N, CPE/Requesting Router=3DUE in Figure 1), and RFC3633.=20 Holger -----Urspr=FCngliche Nachricht----- Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von = Alexandru Petrescu Gesendet: Dienstag, 2. April 2013 16:47 An: Vizdal, Ales Cc: v6ops@ietf.org Betreff: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share= -03 Hello Ales, Sorry for late reply. YEs. This is right. The 3GPP specs there make think that the UE may reque= st several prefixes with DHCPv6 Prefix Delegation. This is new to me. What remains to be seen is how this UE uses these requested prefixes (in ad= dition to the use of the default /64 prefix). I don't think I see anything= in the referred specs about how UE uses these prefixes. This email to say that the 64share document is right how it is now (assumes= DHCPv6-PD in the future, and now just do this method). Alex Le 12/03/2013 04:50, V=EDzdal Ale=B9 a =E9crit : > Hi Alex, > > let's start with TS 29.061 version 10.0.0, Section 11.2.1.3.5 IPv6=20 > Prefix Delegation via DHCPv6 that includes further references. > (http://www.3gpp.org/ftp/Specs/archive/29_series/29.061/29061-a00.zip) > > Cheers, Ales > >> -----Original Message----- From: Alexandru Petrescu=20 >> [mailto:alexandru.petrescu@gmail.com] Sent: Monday, March 11, 2013 >> 11:39 PM To: V=EDzdal Ale=B9 Cc: joel jaeggli; v6ops@ietf.org Subject: >> Re: [v6ops] Mic comments on link model in >> draft-ietf-v6ops-64share-03 >> >> Le 12/03/2013 00:55, V=EDzdal Ale=B9 a =E9crit : >>>>> The 3GPP Rel-10 has introduced DHCP-PD. What's the problem here? >>>> >>>> As far as I can remember, that is a PD for something in the core,=20 >>>> the delegated prefix is for the UE to use on its cellular (not for=20 >>>> the UE to use on its WLAN). >>>> >>>> Were that 3GPP use of DHCPv6-PD to be for a prefix on the UEs WLAN=20 >>>> then... >>>> >>>> Or am I wrong about this? >>> >>> You seem to be wrong here as the PD is intended for an UE to=20 >>> delegate a prefix to a >> LAN. >> >> Please point me to the 3GPP ref? >> >> (last time I checked it was a prefix for the UE on its 3GPP link) >> >> Alex >> >>> >>>> Alex >>> >>> Ales >>> >>> >> > > > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Fri Apr 5 09:12:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E33021F97DE for ; Fri, 5 Apr 2013 09:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.22 X-Spam-Level: X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dduD8Frx-ew for ; Fri, 5 Apr 2013 09:12:36 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8F86D21F97C5 for ; Fri, 5 Apr 2013 09:12:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r35GCX4t029294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 5 Apr 2013 18:12:34 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r35GCX49016843 for ; Fri, 5 Apr 2013 18:12:33 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r35GCVwp020059 for ; Fri, 5 Apr 2013 18:12:33 +0200 Message-ID: <515EF7EF.9000506@gmail.com> Date: Fri, 05 Apr 2013 18:12:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "v6ops@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 16:12:36 -0000 Hello, There is a serious report about the use of IPv6 'tethering' with operator Verizon and doing 'mobile hotspot' with an iPhone. It is not clear though whether that uses the 64share technique described in this document or another one. Alex From cb.list6@gmail.com Fri Apr 5 09:53:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EDA21F976A for ; Fri, 5 Apr 2013 09:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEMa5uqAjx-w for ; Fri, 5 Apr 2013 09:53:05 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 28B1721F8F58 for ; Fri, 5 Apr 2013 09:53:04 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hm14so796508wib.15 for ; Fri, 05 Apr 2013 09:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qeHIpQBxFME4ZG1HuqOXc/y39oRZbUrYMkK+kPZu/ks=; b=oGD/NL07yesnRZP5nGUOlKEkaAIjATSzO+13omctm064RmhN8X6OJgtIq/jy8fXTTd obzTve33xhiXp6Hpe8s7s+Q8UAN/vEIgYVIQ6hVR0JRSdyBoijLOAYq87ciwBG66Ggdz dk3aBtRTkA7dcZno5pVXujxO5pq1bfdAj+pctkKA/NtpVNM8mRxehjeZnmG3rbglJYYJ JC33llrVaxE55xZZUHd9k4y7xVZAyfYaK72UjsyuCX2+HtwSs7VDzWqLY+BNKeevwNyl KsOwR4CEgVZrTXiL9KFMs5mhGe2vy3NjYwylRJIW21PEuulW9JhmlD9kWA80G+w9TU1H nZDA== MIME-Version: 1.0 X-Received: by 10.180.11.136 with SMTP id q8mr5680968wib.18.1365180784298; Fri, 05 Apr 2013 09:53:04 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Fri, 5 Apr 2013 09:53:04 -0700 (PDT) In-Reply-To: <515EF7EF.9000506@gmail.com> References: <515EF7EF.9000506@gmail.com> Date: Fri, 5 Apr 2013 09:53:04 -0700 Message-ID: From: "cb.list6" To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 16:53:05 -0000 On Fri, Apr 5, 2013 at 9:12 AM, Alexandru Petrescu wrote: > Hello, > > There is a serious report about the use of IPv6 'tethering' with > operator Verizon and doing 'mobile hotspot' with an iPhone. > Yes, Apple, ZTE, and Samsung are all known to have a implementations similar in objective to 64share. > It is not clear though whether that uses the 64share technique described > in this document or another one. > These are proprietary implementations that do not conform to any known standard, or ...at least are not openly documented. One of the chief motivations for the 64share draft is to have a known and open model that has been openly peer reviewed and can be referenced as the desired model for the specific scope of the I-D. Cameron > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Fri Apr 5 10:42:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A0C21F985D for ; Fri, 5 Apr 2013 10:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.922 X-Spam-Level: X-Spam-Status: No, score=-9.922 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSJ9-f08nS2O for ; Fri, 5 Apr 2013 10:42:04 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C1F9B21F985C for ; Fri, 5 Apr 2013 10:42:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r35Hg2n4031285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Apr 2013 19:42:02 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r35Hg13G031225; Fri, 5 Apr 2013 19:42:02 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r35HfwPO031042; Fri, 5 Apr 2013 19:42:01 +0200 Message-ID: <515F0CE6.2020103@gmail.com> Date: Fri, 05 Apr 2013 19:41:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "cb.list6" References: <515EF7EF.9000506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 17:42:04 -0000 Le 05/04/2013 18:53, cb.list6 a écrit : > On Fri, Apr 5, 2013 at 9:12 AM, Alexandru Petrescu > wrote: >> Hello, >> >> There is a serious report about the use of IPv6 'tethering' with >> operator Verizon and doing 'mobile hotspot' with an iPhone. >> > > Yes, Apple, ZTE, and Samsung are all known to have a implementations > similar in objective to 64share. > >> It is not clear though whether that uses the 64share technique >> described in this document or another one. >> > > These are proprietary implementations that do not conform to any > known standard, or ...at least are not openly documented. > > One of the chief motivations for the 64share draft is to have a known > and open model that has been openly peer reviewed and can be > referenced as the desired model for the specific scope of the I-D. Cameron, Reflecting implementation as much as possible to specification is good. There may exist indicators by which one could say how much an implementation is reflected in specification. For 64share it's easy to suggest an appoximate test of conformance (without having access to source code). Alex > > Cameron > >> Alex >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Fri Apr 5 10:54:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7D721F9782 for ; Fri, 5 Apr 2013 10:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.908 X-Spam-Level: X-Spam-Status: No, score=-9.908 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V93PGLvlkVb7 for ; Fri, 5 Apr 2013 10:54:30 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id B64C021F973C for ; Fri, 5 Apr 2013 10:54:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r35HsS3x011973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 5 Apr 2013 19:54:28 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r35HsSuo032751 for ; Fri, 5 Apr 2013 19:54:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r35HsOAw017438 for ; Fri, 5 Apr 2013 19:54:28 +0200 Message-ID: <515F0FD0.6090004@gmail.com> Date: Fri, 05 Apr 2013 19:54:24 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <515EF7EF.9000506@gmail.com> <515F0CE6.2020103@gmail.com> In-Reply-To: <515F0CE6.2020103@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 17:54:31 -0000 Le 05/04/2013 19:41, Alexandru Petrescu a écrit : > Le 05/04/2013 18:53, cb.list6 a écrit : >> On Fri, Apr 5, 2013 at 9:12 AM, Alexandru Petrescu >> wrote: >>> Hello, >>> >>> There is a serious report about the use of IPv6 'tethering' with >>> operator Verizon and doing 'mobile hotspot' with an iPhone. >>> >> >> Yes, Apple, ZTE, and Samsung are all known to have a >> implementations similar in objective to 64share. >> >>> It is not clear though whether that uses the 64share technique >>> described in this document or another one. >>> >> >> These are proprietary implementations that do not conform to any >> known standard, or ...at least are not openly documented. >> >> One of the chief motivations for the 64share draft is to have a >> known and open model that has been openly peer reviewed and can be >> referenced as the desired model for the specific scope of the I-D. > > Cameron, > > Reflecting implementation as much as possible to specification is > good. > > There may exist indicators by which one could say how much an > implementation is reflected in specification. For 64share it's easy > to suggest an appoximate test of conformance (without having access > to source code). For example: compare the address of the smartphone (having 'Personal Hotspot' off) with the address of the other PC in the hotspot (smartphone sets 'Personal Hotspot'). Are they the same on the first 64bits? If yes then the solution is likely to be 64share. If no, then the solution is mobile hotspot, but may not be 64share. More details could be tested. Alex > > Alex > >> >> Cameron >> >>> Alex >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From internet-drafts@ietf.org Fri Apr 5 15:18:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0184921F84CA; Fri, 5 Apr 2013 15:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TOifa-bYn2V; Fri, 5 Apr 2013 15:18:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B21421F84CD; Fri, 5 Apr 2013 15:18:19 -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.43.p3 Message-ID: <20130405221819.7519.42664.idtracker@ietfa.amsl.com> Date: Fri, 05 Apr 2013 15:18:19 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:18:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interfac= e to a LAN Author(s) : Cameron Byrne Dan Drown Ales Vizdal Filename : draft-ietf-v6ops-64share-04.txt Pages : 8 Date : 2013-04-05 Abstract: This document describes three methods for extending an IPv6 /64 prefix from a User Equipment 3GPP radio interface to a LAN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-64share-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mackermann@bcbsm.com Thu Apr 11 09:57:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DBB21F8FC0 for ; Thu, 11 Apr 2013 09:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GODxqleuCPkG for ; Thu, 11 Apr 2013 09:57:02 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 40B9B21F9058 for ; Thu, 11 Apr 2013 09:57:00 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id D19D39ADAEB for ; Thu, 11 Apr 2013 11:56:59 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 6590E9ADAE4; Thu, 11 Apr 2013 11:56:59 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id E47712F004A; Thu, 11 Apr 2013 12:54:44 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva2.bcbsm.com (Postfix) with ESMTP id D3E982F0043; Thu, 11 Apr 2013 12:54:44 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0438.000; Thu, 11 Apr 2013 12:56:58 -0400 From: "Ackermann, Michael" To: "v6ops@ietf.org" Thread-Topic: IPV6 Operational and Implementation guide? Thread-Index: Ac421ZOm12BusRf6TWqN9HwIy/ds6g== Date: Thu, 11 Apr 2013 16:56:57 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A684528@PWN401EA160.ent.corp.bcbsm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0A684528PWN401EA160entc_" MIME-Version: 1.0 Subject: [v6ops] IPV6 Operational and Implementation guide? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 16:57:03 -0000 --_000_4FC37E442D05A748896589E468752CAA0A684528PWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the most recent IETF Meeting in Orlando, a presentation was given = regarding a document which contained guidelines for implementing and = operating IPv6. I agreed to review and comment on this document. BUT I cannot find it. Can anyone help me locate this document? Thanks, Mike The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0A684528PWN401EA160entc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

At the most recent IETF Meeting in Orlando, a = presentation was given regarding a document which contained guidelines for = implementing and operating IPv6. 

 

I agreed to review and comment on this = document.

 

BUT

 

I cannot find it. 

 

Can anyone help me locate this document?  =

 

Thanks,

 

Mike

 

 


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_4FC37E442D05A748896589E468752CAA0A684528PWN401EA160entc_-- From aservin@lacnic.net Thu Apr 11 10:22:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E054A21F87B1 for ; Thu, 11 Apr 2013 10:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlcUjqEqqhCU for ; Thu, 11 Apr 2013 10:22:23 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id DD77421F86F7 for ; Thu, 11 Apr 2013 10:22:22 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:7000:95d8:e0af:510:ea86]) by mail.lacnic.net.uy (Postfix) with ESMTP id 82DFB308465 for ; Thu, 11 Apr 2013 14:22:01 -0300 (UYT) Message-ID: <5166F142.8010204@lacnic.net> Date: Thu, 11 Apr 2013 14:22:10 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: v6ops@ietf.org References: <4FC37E442D05A748896589E468752CAA0A684528@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A684528@PWN401EA160.ent.corp.bcbsm.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [v6ops] IPV6 Operational and Implementation guide? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 17:22:25 -0000 Was about datacenters? If so, this is the link: http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/ Regards, /as On 4/11/13 1:56 PM, Ackermann, Michael wrote: > At the most recent IETF Meeting in Orlando, a presentation was given > regarding a document which contained guidelines for implementing and > operating IPv6. > > > > I agreed to review and comment on this document. > > > > BUT > > > > I cannot find it. > > > > Can anyone help me locate this document? > > > > Thanks, > > > > Mike > > > > > > > The information contained in this communication is highly confidential > and is intended solely for the use of the individual(s) to whom this > communication is directed. If you are not the intended recipient, you > are hereby notified that any viewing, copying, disclosure or > distribution of this information is prohibited. Please notify the > sender, by electronic mail or telephone, of any unintended receipt and > delete the original message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are > nonprofit corporations and independent licensees of the Blue Cross and > Blue Shield Association. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From simon.perreault@viagenie.ca Fri Apr 12 01:07:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537FB21F86B7 for ; Fri, 12 Apr 2013 01:07:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trAbssapR6Bg for ; Fri, 12 Apr 2013 01:07:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id AB4DA21F8555 for ; Fri, 12 Apr 2013 01:07:27 -0700 (PDT) Received: from porto.nomis80.org (unknown [193.49.160.97]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 053FA403D1 for ; Fri, 12 Apr 2013 04:06:56 -0400 (EDT) Message-ID: <5167C0A1.2070503@viagenie.ca> Date: Fri, 12 Apr 2013 10:06:57 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <4FC37E442D05A748896589E468752CAA0A684528@PWN401EA160.ent.corp.bcbsm.com> <5166F142.8010204@lacnic.net> In-Reply-To: <5166F142.8010204@lacnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] IPV6 Operational and Implementation guide? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 08:07:28 -0000 Le 2013-04-11 19:22, Arturo Servin a écrit : > > Was about datacenters? Or was it about enterprise? http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6 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 brian.e.carpenter@gmail.com Fri Apr 12 03:38:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28D321F892D for ; Fri, 12 Apr 2013 03:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.515 X-Spam-Level: X-Spam-Status: No, score=-99.515 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+EZQWiHfUUc for ; Fri, 12 Apr 2013 03:38:28 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2699A21F892B for ; Fri, 12 Apr 2013 03:38:27 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id m15so89970wgh.0 for ; Fri, 12 Apr 2013 03:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PGkobRfTf0trh4/bz5bGOnq8PzrMvWtgh7Pv38EjQaY=; b=tihzH+qy1QXp94L8xjYCZNBUMkWTVH/cWB/J1bvblhV9TSjnkkpFuzbzGmXh5953FX W+TN+RQOSwvFSqujXi4NayMJ/72o6ZTBctHxRY0jdTgr6STcg3xLYdf6IZvjoT0ylqgT oAZXFpxcckKiYSSXz3FtbUNWK8FsCnxsTzP9k76KHB0/YFwBHGBGy2BU0rsfAThB78Qd snGFs0XB+4QXjVJCfWa1+x388Xi5FkKxGjnZebrvNcPsiuT4FV7Jtsv1t13d9gfEXCHk CmR71fXo3kzc8GVzI5a3NLL2dD0tpNZO5JDHjXacX8lD9aj+u3Dn/cnIRs6n47gG8bnF 5ccg== X-Received: by 10.180.87.170 with SMTP id az10mr3173111wib.3.1365763106616; Fri, 12 Apr 2013 03:38:26 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-188-167.as13285.net. [2.101.188.167]) by mx.google.com with ESMTPS id o5sm2808382wix.3.2013.04.12.03.38.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Apr 2013 03:38:25 -0700 (PDT) Message-ID: <5167E42D.60905@gmail.com> Date: Fri, 12 Apr 2013 11:38:37 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault References: <4FC37E442D05A748896589E468752CAA0A684528@PWN401EA160.ent.corp.bcbsm.com> <5166F142.8010204@lacnic.net> <5167C0A1.2070503@viagenie.ca> In-Reply-To: <5167C0A1.2070503@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] IPV6 Operational and Implementation guide? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 10:38:28 -0000 On 12/04/2013 09:06, Simon Perreault wrote: > Le 2013-04-11 19:22, Arturo Servin a =C3=A9crit : >> >> Was about datacenters? >=20 > Or was it about enterprise? >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6= Also, the one for content providers is already out as RFC 6883. Brian From markzzzsmith@yahoo.com.au Fri Apr 12 03:40:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C096621F8B13 for ; Fri, 12 Apr 2013 03:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFKR+NR+q9O7 for ; Fri, 12 Apr 2013 03:40:41 -0700 (PDT) Received: from nm15-vm0.bullet.mail.bf1.yahoo.com (nm15-vm0.bullet.mail.bf1.yahoo.com [98.139.212.254]) by ietfa.amsl.com (Postfix) with SMTP id 114AC21F8B08 for ; Fri, 12 Apr 2013 03:40:40 -0700 (PDT) Received: from [98.139.214.32] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 12 Apr 2013 10:40:40 -0000 Received: from [98.139.212.249] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 12 Apr 2013 10:40:40 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 12 Apr 2013 10:40:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 502883.15195.bm@omp1058.mail.bf1.yahoo.com Received: (qmail 29845 invoked by uid 60001); 12 Apr 2013 10:40:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1365763240; bh=NZWROX6CIoh2PvSbSnvCHMkYr+Sa17+eZNvTDuhnAiI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Azb72iUuxM3yATB0ZLcDblUHEraxGciALs+iTjWVJlUq7ZTFfaZjbHyF11o8rOrIU7LYclfEcPe9sAEGev6zahIexnOi6EbpexYEHvjn8hMuYuIpvpNdqnZ/Cpm2Be+MSKYyvRD1Z8IwXACYiIcutRWChnHNKroiYBuJZUwZ02g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1has5/446i2jG9iFBQJzeyFjns2UuvaftRPiP62sn5hFgqXj+3ad7xdC1gH92De+Lgu0BYzUqlDK9krEqM5SQtVYFCfkXQplMZRtTv76jsfGigQRlBZh8Qi4ijzF1x4+JOgD/+rHfnIexpNXWC7jrv/3qhEQMdbxCPJ2ntMvOyQ=; X-YMail-OSG: ACV6G8wVM1kSrMhQjMfxEmRevnCLoJWRh78G09yfwfFBTka OWuNs6Z35uXif8xd0Vl05Urcjwi96QWXEDRqp7U1zRnrRqIID5VrSt3iE6WQ _wmWBzzYNbJfiJkXHgleMnQ06co6mnYhwqHbOgmxdsjflFiM4jwqxaUQwj0z 5mk0WIuaml3nqI_jBJJlZqVi5I4Ms_nY2hiK6NPUTy0v2rnyhmkAcLA1fU9h A69EpzkoJPor5qTFjQLFpuvLj2HtB9aNJQSeI03SUh3AUDGlAFs.Ang9wFPE Hfv_D202uNsraSy4D7Dm6tDH0a1g4IwUknPtBkHqMMp3BAUNTaj0VMJzi06D _.hJQhxnbkR36MaZqnsw1_2JqMibqJxI1AzG1e0YGD1FfvPiS6NnV2NUD6_x aCTvuPmMlmgdWbXqqqtL59lIVxesjpspIOxBeP4sGcovVNa83LmoWS1av2zI 8FG3LLv_R3qf4zRHgluvs9bPE5BF3ttTjF1QjjWILJd_ZWN0s4o_iKvHU9HA FOTsa__re7.q5mV8B5_QrumLanQM9wPHsZXVT0cJqOKNebpMgYYeum7YSFjy PBmC_GGKNUGfeqHvZ7tM4X2BWLQ-- Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Fri, 12 Apr 2013 03:40:40 PDT X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBTaW1vbiBQZXJyZWF1bHQgPHNpbW9uLnBlcnJlYXVsdEB2aWFnZW5pZS5jYT4KPlRvOiB2Nm9wc0BpZXRmLm9yZyAKPlNlbnQ6IEZyaWRheSwgMTIgQXByaWwgMjAxMyA2OjA2IFBNCj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBJUFY2IE9wZXJhdGlvbmFsIGFuZCBJbXBsZW1lbnRhdGlvbiBndWlkZT8KPiAKPgo.TGUgMjAxMy0wNC0xMSAxOToyMiwgQXJ0dXJvIFNlcnZpbiBhIMOpY3JpdCA6Cj4.Cj4.IMKgwqDCoCBXYXMgYWJvdXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.140.532 References: <4FC37E442D05A748896589E468752CAA0A684528@PWN401EA160.ent.corp.bcbsm.com> <5166F142.8010204@lacnic.net> <5167C0A1.2070503@viagenie.ca> Message-ID: <1365763240.29178.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Fri, 12 Apr 2013 03:40:40 -0700 (PDT) From: Mark Smith To: Simon Perreault , "v6ops@ietf.org" In-Reply-To: <5167C0A1.2070503@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] IPV6 Operational and Implementation guide? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 10:40:41 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Simon Perreault = =0A>To: v6ops@ietf.org =0A>Sent: Friday, 12 Ap= ril 2013 6:06 PM=0A>Subject: Re: [v6ops] IPV6 Operational and Implementatio= n guide?=0A> =0A>=0A>Le 2013-04-11 19:22, Arturo Servin a =E9crit :=0A>>=0A= >> =A0=A0=A0 Was about datacenters?=0A>=0A>Or was it about enterprise?=0A>= =0A>http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6= =0A>=0A>=0A>Sounds like this one:=0A>=0A>=0A>"Design Choices for IPv6 Netwo= rks"=0A>https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-00=0A>= =0A>=0A>=0A>Simon=0A>-- =0A>DTN made easy, lean, and smart --> http://poste= llation.viagenie.ca=0A>NAT64/DNS64 open-source=A0 =A0 =A0 =A0 --> http://ec= dysis.viagenie.ca=0A>STUN/TURN server=A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http:= //numb.viagenie.ca=0A>_______________________________________________=0A>v6= ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf.org/mailman/listinfo= /v6ops=0A>=0A>=0A> From leo.liubing@huawei.com Fri Apr 12 03:42:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DE921F84F6 for ; Fri, 12 Apr 2013 03:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5UhaDmR+9kH for ; Fri, 12 Apr 2013 03:42:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3717121F84F9 for ; Fri, 12 Apr 2013 03:42:15 -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 AQH89792; Fri, 12 Apr 2013 10:42:11 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Apr 2013 11:41:30 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Apr 2013 11:42:09 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Fri, 12 Apr 2013 18:42:04 +0800 From: "Liubing (Leo)" To: Simon Perreault , "v6ops@ietf.org" , "MAckermann@bcbsm.com" Thread-Topic: [v6ops] IPV6 Operational and Implementation guide? Thread-Index: Ac421ZOm12BusRf6TWqN9HwIy/ds6v//gO4AgAD3NYD//1A94A== Date: Fri, 12 Apr 2013 10:42:04 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEBDE@nkgeml506-mbx.china.huawei.com> References: <4FC37E442D05A748896589E468752CAA0A684528@PWN401EA160.ent.corp.bcbsm.com> <5166F142.8010204@lacnic.net> <5167C0A1.2070503@viagenie.ca> In-Reply-To: <5167C0A1.2070503@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] IPV6 Operational and Implementation guide? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 10:42:20 -0000 > Le 2013-04-11 19:22, Arturo Servin a =E9crit : > > > > Was about datacenters? >=20 > Or was it about enterprise? >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6 As I took the notes, it was datacenters (http://datatracker.ietf.org/doc/dr= aft-lopez-v6ops-dc-ipv6/) But it would be great if the enterprise draft could be reviewed as well :-) B.R. Bing > 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From leo.liubing@huawei.com Fri Apr 12 04:10:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52A621F8618 for ; Fri, 12 Apr 2013 04:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGdY15XBHdBP for ; Fri, 12 Apr 2013 04:10:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CC4D721F8994 for ; Fri, 12 Apr 2013 04:10:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ART94274; Fri, 12 Apr 2013 11:10:51 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Apr 2013 12:10:11 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Apr 2013 19:10:50 +0800 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Fri, 12 Apr 2013 19:10:44 +0800 From: "Liubing (Leo)" To: Mark Smith , "v6ops@ietf.org" Thread-Topic: [v6ops] IPV6 Operational and Implementation guide? Thread-Index: Ac421ZOm12BusRf6TWqN9HwIy/ds6v//gO4AgAD3NYCAACrzAP//c1ZA Date: Fri, 12 Apr 2013 11:10:43 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEBFA@nkgeml506-mbx.china.huawei.com> References: <4FC37E442D05A748896589E468752CAA0A684528@PWN401EA160.ent.corp.bcbsm.com> <5166F142.8010204@lacnic.net> <5167C0A1.2070503@viagenie.ca> <1365763240.29178.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1365763240.29178.YahooMailNeo@web142505.mail.bf1.yahoo.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] IPV6 Operational and Implementation guide? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:10:56 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Mark Smith > >Sounds like this one: > > > > > >"Design Choices for IPv6 Networks" > >https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-00 This one was took off the agenda at the meeting due to the author's request= . It was an update from individual draft to WG item with not too much revis= ion. From alexandru.petrescu@gmail.com Fri Apr 12 04:37:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA6E21F88B9 for ; Fri, 12 Apr 2013 04:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmzbrgMkB9aV for ; Fri, 12 Apr 2013 04:37:03 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id C08CB21F86B7 for ; Fri, 12 Apr 2013 04:37:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r3CBb1AS030288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 12 Apr 2013 13:37:01 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r3CBb1kT025286 for ; Fri, 12 Apr 2013 13:37:01 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r3CBb0AC012656 for ; Fri, 12 Apr 2013 13:37:01 +0200 Message-ID: <5167F1DC.7040608@gmail.com> Date: Fri, 12 Apr 2013 13:37:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: v6ops@ietf.org References: <4FC37E442D05A748896589E468752CAA0A684528@PWN401EA160.ent.corp.bcbsm.com> <5166F142.8010204@lacnic.net> <5167C0A1.2070503@viagenie.ca> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEBDE@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEBDE@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] IPV6 Operational and Implementation guide? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:37:03 -0000 Le 12/04/2013 12:42, Liubing (Leo) a écrit : >> Le 2013-04-11 19:22, Arturo Servin a écrit : >>> >>> Was about datacenters? >> >> Or was it about enterprise? >> >> http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6 The enterprise deployment draft came up in various room and hallway discussions as well. Alex > > As I took the notes, it was datacenters > (http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/) > > But it would be great if the enterprise draft could be reviewed as > well :-) > > B.R. Bing > >> 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 >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From mackermann@bcbsm.com Fri Apr 12 05:48:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067B121F87C5 for ; Fri, 12 Apr 2013 05:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6FIZTRjrYay for ; Fri, 12 Apr 2013 05:48:56 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 16C3621F8804 for ; Fri, 12 Apr 2013 05:48:50 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id BEEB59ADAE2 for ; Fri, 12 Apr 2013 07:48:49 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 64F739ADAD6 for ; Fri, 12 Apr 2013 07:48:49 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 7106D4F8059 for ; Fri, 12 Apr 2013 08:46:35 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id 64F134F8051 for ; Fri, 12 Apr 2013 08:46:35 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0438.000; Fri, 12 Apr 2013 08:48:48 -0400 From: "Ackermann, Michael" To: "v6ops@ietf.org" Thread-Topic: [v6ops] IPV6 Operational and Implementation guide? Thread-Index: Ac421ZOm12BusRf6TWqN9HwIy/ds6gAJQysAAB7mlYAABWraAAAB6yQAAAXnf/A= Date: Fri, 12 Apr 2013 12:48:47 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A684AC8@PWN401EA160.ent.corp.bcbsm.com> References: <4FC37E442D05A748896589E468752CAA0A684528@PWN401EA160.ent.corp.bcbsm.com> <5166F142.8010204@lacnic.net> <5167C0A1.2070503@viagenie.ca> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEBDE@nkgeml506-mbx.china.huawei.com> <5167F1DC.7040608@gmail.com> In-Reply-To: <5167F1DC.7040608@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] IPV6 Operational and Implementation guide? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 12:48:57 -0000 Thanks to all who responded to this.=20 And YES, I will review all of them. (we need all the help we can get = here=21) =20 :) THanks Mike -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Alexandru Petrescu Sent: Friday, April 12, 2013 7:37 AM To: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D IPV6 Operational and Implementation guide? Le 12/04/2013 12:42, Liubing (Leo) a =E9crit : >> Le 2013-04-11 19:22, Arturo Servin a =E9crit : >>> >>> Was about datacenters? >> >> Or was it about enterprise? >> >> http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ip >> v6 The enterprise deployment draft came up in various room and hallway = discussions as well. Alex > > As I took the notes, it was datacenters > (http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/) > > But it would be great if the enterprise draft could be reviewed as=20 > well :-) > > B.R. Bing > >> 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 >> _______________________________________________ v6ops mailing list=20 >> v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list=20 > v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From alexandru.petrescu@gmail.com Fri Apr 12 07:45:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0330721F892B for ; Fri, 12 Apr 2013 07:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfXtWzJ8YTDT for ; Fri, 12 Apr 2013 07:45:06 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id B9DA321F874A for ; Fri, 12 Apr 2013 07:44:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r3CEiwFC005608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 12 Apr 2013 16:44:58 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r3CEiwmA015599 for ; Fri, 12 Apr 2013 16:44:58 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r3CEipUV028907 for ; Fri, 12 Apr 2013 16:44:57 +0200 Message-ID: <51681DE3.1060407@gmail.com> Date: Fri, 12 Apr 2013 16:44:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: v6ops@ietf.org References: <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 14:45:07 -0000 Since this discussion happened we went on experimenting. The discussion was in the context of ULA usage and in some way about whether or not various platforms implement RIO Route Information Option (RFC 4191 "Default Router Preferences and More Specific Routes"). Linux does it. Le 22/03/2013 04:52, Owen DeLong a écrit : [...] >>> I don't know how to help you operate your equipment. I use >>> different equipment. However, even if it is not possible with >>> your equipment, see above. >> >> Do you know of any equipment that actually supports RIO? > > I haven't done such an analysis as it hasn't been important until > now. I've avoided the use of ULAs which helps a lot. We've tested the use of RIO in linux recent kernels 3.8.x. The RIO option is there in the kernel with two different statuses. First, the Pref field which applies only to configuring a DEfault Router with preferences is present ok; otoh its suboption of using a PIO is stated as "EXPERIMENTAL" which in linux lingo means to be careful about it; in this case the carefulness is a security warning (although IMHO it's just as insecure to allow DEfault Router preferences). The implementation works fine between two routers sending each other RAs with PIO. The software radvd.conf sends the RA and the receiving kernel interprets the PIO and adds routes in its routing table, provided it has the forwarding==2. There are some questions about lifetime, but we'll see later. With respect to ULAs, the prefix we've put in the PIO is a ULA. We used the prefix fd00:f00d:1::/64; that has 'food' because we have a hard time to generate a random and syntactically correct prefix. We used a ULA because the experiment took one week and that's not enough time to learn how to get a PA space and do it. Alex > Owen > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From brian.e.carpenter@gmail.com Fri Apr 12 08:21:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E049F21F87D0 for ; Fri, 12 Apr 2013 08:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.768 X-Spam-Level: X-Spam-Status: No, score=-100.768 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaiqpfy8sqDh for ; Fri, 12 Apr 2013 08:21:41 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 07B1721F84AE for ; Fri, 12 Apr 2013 08:21:40 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so2760305wgh.17 for ; Fri, 12 Apr 2013 08:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7B4sODEiTMsVdbFlJA4hWtyBm2HPGKanG3qrLJVBd+4=; b=ApRVhTaiaSWP9vIa0NTk8FbqvHvAa8d4nyMn2JzeMVZsOvlG+ZAzrSVWBrsrQmO5Hh Hs2F6NYpxIhgSJ6oX33/lhjIVzw1aY8Qzd3Wy97SWOybBOk7ylCRUtCOQWJxZvWt11l2 ZAZQPbBrtcj3tF48nJFlW7Jpep/AnsRyp+by9Fc36JSIswJ9VIIqlDcoTUIdG9DdA5eP oOru66rTCoj6gUx7pNxbdeWtkOulmq3FitlaVtXb7otBykJ/dFDnvh3W87WiFUSrVjqs YsJHNm5eUMGUPA6toOzhEXOkZFlwkscTjBvEVWIxVQULS0Lvacxao++8sswJVJj1Rs8g wckQ== X-Received: by 10.180.19.39 with SMTP id b7mr4880612wie.15.1365780100208; Fri, 12 Apr 2013 08:21:40 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-188-167.as13285.net. [2.101.188.167]) by mx.google.com with ESMTPS id h10sm4281806wic.8.2013.04.12.08.21.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Apr 2013 08:21:39 -0700 (PDT) Message-ID: <51682690.4040809@gmail.com> Date: Fri, 12 Apr 2013 16:21:52 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <51681DE3.1060407@gmail.com> In-Reply-To: <51681DE3.1060407@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:21:42 -0000 On 12/04/2013 15:44, Alexandru Petrescu wrote: ... > With respect to ULAs, the prefix we've put in the PIO is a ULA. We used > the prefix fd00:f00d:1::/64; that has 'food' because we have a hard time > to generate a random and syntactically correct prefix. Really? http://www.sixxs.net/tools/grh/ula/ Brian From alexandru.petrescu@gmail.com Fri Apr 12 08:26:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647B221F8D28 for ; Fri, 12 Apr 2013 08:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aoh3iuLDuYgJ for ; Fri, 12 Apr 2013 08:26:26 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0E86621F8BAE for ; Fri, 12 Apr 2013 08:26:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r3CFQMNk023307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Apr 2013 17:26:22 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r3CFQMqR029941; Fri, 12 Apr 2013 17:26:22 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r3CFQILS016706; Fri, 12 Apr 2013 17:26:22 +0200 Message-ID: <5168279A.8030704@gmail.com> Date: Fri, 12 Apr 2013 17:26:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Brian E Carpenter References: <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <51681DE3.1060407@gmail.com> <51682690.4040809@gmail.com> In-Reply-To: <51682690.4040809@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:26:27 -0000 Le 12/04/2013 17:21, Brian E Carpenter a écrit : > On 12/04/2013 15:44, Alexandru Petrescu wrote: ... >> With respect to ULAs, the prefix we've put in the PIO is a ULA. We >> used the prefix fd00:f00d:1::/64; that has 'food' because we have a >> hard time to generate a random and syntactically correct prefix. > > Really? http://www.sixxs.net/tools/grh/ula/ That GUI may be helpful. It is a good starting point, we will try to use it in general. However, in one particular case it's not clear _which_ EUI-64 to use? A Router has two interfaces - two such EUI-64. The ULA prefix which is PIO (Prefix Information Option) on one interface is RIO on the other interface. Which EUI-64 to use? Alex > > Brian > > From arturo.servin@gmail.com Fri Apr 12 08:35:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B4621F8D8E for ; Fri, 12 Apr 2013 08:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBH3ypJ6+Ebv for ; Fri, 12 Apr 2013 08:35:08 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id A7F8E21F8C0C for ; Fri, 12 Apr 2013 08:35:02 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id 25so432373yhr.9 for ; Fri, 12 Apr 2013 08:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GT8Nn2bP9XqsZcfXaDShNxcX4MAvPHceG7XcPlyhDEM=; b=aWN7xnfinULTTp4fT0ZfgRwZsEp4ZFGnbY2RcyWM2AUgDs5F9QHtLq8HsrXMnmhvYF xnKwU3cmOAIudXkDVNrwyj0YEBeLmSOZq72We6i7D2tij9BMDumEULAMwivc891K0RZm 6CtLDprAC+5jw/gfivlAYOe2qBjtbsFIEDnxdCAvnqrBcawo85piyBxxkGeFfIT4YWYw YRCvMZRV68HHD1+hdW3hPaatuzpUyGVAuzwNcU8DxHuhdeUVLjaQAKa7L3e/srhPac6H Y0EdFnGdRlNkpmnejC8ahlzmfHX3nztxbrEvuEr1c+TRQ1vbyYCxXCdlbLoFVlA6t4gZ Pg0w== X-Received: by 10.236.81.75 with SMTP id l51mr217396yhe.75.1365780902217; Fri, 12 Apr 2013 08:35:02 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([2001:13c7:7001:7000:d942:c63f:a742:a337]) by mx.google.com with ESMTPS id y5sm12358565yhd.3.2013.04.12.08.35.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Apr 2013 08:35:01 -0700 (PDT) Message-ID: <516829A1.9060602@gmail.com> Date: Fri, 12 Apr 2013 12:34:57 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: v6ops@ietf.org References: <4FC37E442D05A748896589E468752CAA0A684528@PWN401EA160.ent.corp.bcbsm.com> <5166F142.8010204@lacnic.net> <5167C0A1.2070503@viagenie.ca> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEBDE@nkgeml506-mbx.china.huawei.com> <5167F1DC.7040608@gmail.com> <4FC37E442D05A748896589E468752CAA0A684AC8@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A684AC8@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] IPV6 Operational and Implementation guide? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:35:08 -0000 Thanks! .as On 4/12/13 9:48 AM, Ackermann, Michael wrote: > Thanks to all who responded to this. > > And YES, I will review all of them. (we need all the help we can get here!) > :) > > THanks > > Mike > > > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Friday, April 12, 2013 7:37 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] IPV6 Operational and Implementation guide? > > Le 12/04/2013 12:42, Liubing (Leo) a écrit : >>> Le 2013-04-11 19:22, Arturo Servin a écrit : >>>> >>>> Was about datacenters? >>> >>> Or was it about enterprise? >>> >>> http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ip >>> v6 > > The enterprise deployment draft came up in various room and hallway discussions as well. > > Alex > >> >> As I took the notes, it was datacenters >> (http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/) >> >> But it would be great if the enterprise draft could be reviewed as >> well :-) >> >> B.R. Bing >> >>> 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 >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From simon.perreault@viagenie.ca Fri Apr 12 08:35:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8249621F8DB2 for ; Fri, 12 Apr 2013 08:35:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzZzSH-TkwAJ for ; Fri, 12 Apr 2013 08:35:49 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 51D4421F8DB6 for ; Fri, 12 Apr 2013 08:35:48 -0700 (PDT) Received: from porto.nomis80.org (unknown [193.49.160.97]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A4A3A403E7 for ; Fri, 12 Apr 2013 11:35:17 -0400 (EDT) Message-ID: <516829B5.40304@viagenie.ca> Date: Fri, 12 Apr 2013 17:35:17 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <51681DE3.1060407@gmail.com> <51682690.4040809@gmail.com> <5168279A.8030704@gmail.com> In-Reply-To: <5168279A.8030704@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:35:50 -0000 Le 2013-04-12 17:26, Alexandru Petrescu a écrit : > Le 12/04/2013 17:21, Brian E Carpenter a écrit : >> On 12/04/2013 15:44, Alexandru Petrescu wrote: ... >>> With respect to ULAs, the prefix we've put in the PIO is a ULA. We >>> used the prefix fd00:f00d:1::/64; that has 'food' because we have a >>> hard time to generate a random and syntactically correct prefix. >> >> Really? http://www.sixxs.net/tools/grh/ula/ > > That GUI may be helpful. It is a good starting point, we will try to > use it in general. > > However, in one particular case it's not clear _which_ EUI-64 to use? > > A Router has two interfaces - two such EUI-64. The ULA prefix which is > PIO (Prefix Information Option) on one interface is RIO on the other > interface. > > Which EUI-64 to use? Why do you think it matters? 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 alexandru.petrescu@gmail.com Fri Apr 12 08:44:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6889621F8E6A for ; Fri, 12 Apr 2013 08:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.129 X-Spam-Level: X-Spam-Status: No, score=-10.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCxPDnf1yCkl for ; Fri, 12 Apr 2013 08:44:47 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6298821F8D46 for ; Fri, 12 Apr 2013 08:44:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r3CFikKc030308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 12 Apr 2013 17:44:46 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r3CFikrg002206 for ; Fri, 12 Apr 2013 17:44:46 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r3CFigYL031721 for ; Fri, 12 Apr 2013 17:44:46 +0200 Message-ID: <51682BEA.2080802@gmail.com> Date: Fri, 12 Apr 2013 17:44:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: v6ops@ietf.org References: <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <51681DE3.1060407@gmail.com> <51682690.4040809@gmail.com> <5168279A.8030704@gmail.com> <516829B5.40304@viagenie.ca> In-Reply-To: <516829B5.40304@viagenie.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:44:48 -0000 Le 12/04/2013 17:35, Simon Perreault a écrit : > Le 2013-04-12 17:26, Alexandru Petrescu a écrit : >> Le 12/04/2013 17:21, Brian E Carpenter a écrit : >>> On 12/04/2013 15:44, Alexandru Petrescu wrote: ... >>>> With respect to ULAs, the prefix we've put in the PIO is a ULA. >>>> We used the prefix fd00:f00d:1::/64; that has 'food' because we >>>> have a hard time to generate a random and syntactically correct >>>> prefix. >>> >>> Really? http://www.sixxs.net/tools/grh/ula/ >> >> That GUI may be helpful. It is a good starting point, we will try >> to use it in general. >> >> However, in one particular case it's not clear _which_ EUI-64 to >> use? >> >> A Router has two interfaces - two such EUI-64. The ULA prefix >> which is PIO (Prefix Information Option) on one interface is RIO on >> the other interface. >> >> Which EUI-64 to use? > > Why do you think it matters? Because if not then everyone would use the same? (hence more risk of collision?) Another unique identifier which would cover the Router entirely, not only one of its interfaces, would be better. Alex > > Simon From simon.perreault@viagenie.ca Fri Apr 12 09:30:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC5921F8ED6 for ; Fri, 12 Apr 2013 09:30: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOmSQ8DqON4m for ; Fri, 12 Apr 2013 09:30:49 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id BDBE721F8ED5 for ; Fri, 12 Apr 2013 09:30:49 -0700 (PDT) Received: from porto.nomis80.org (unknown [193.49.160.97]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2F61C403E7 for ; Fri, 12 Apr 2013 12:30:19 -0400 (EDT) Message-ID: <5168369A.7090504@viagenie.ca> Date: Fri, 12 Apr 2013 18:30:18 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <51681DE3.1060407@gmail.com> <51682690.4040809@gmail.com> <5168279A.8030704@gmail.com> <516829B5.40304@viagenie.ca> <51682BEA.2080802@gmail.com> In-Reply-To: <51682BEA.2080802@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 16:30:51 -0000 Le 2013-04-12 17:44, Alexandru Petrescu a écrit : > Le 12/04/2013 17:35, Simon Perreault a écrit : >> Le 2013-04-12 17:26, Alexandru Petrescu a écrit : >>> Le 12/04/2013 17:21, Brian E Carpenter a écrit : >>>> On 12/04/2013 15:44, Alexandru Petrescu wrote: ... >>>>> With respect to ULAs, the prefix we've put in the PIO is a ULA. >>>>> We used the prefix fd00:f00d:1::/64; that has 'food' because we >>>>> have a hard time to generate a random and syntactically correct >>>>> prefix. >>>> >>>> Really? http://www.sixxs.net/tools/grh/ula/ >>> >>> That GUI may be helpful. It is a good starting point, we will try >>> to use it in general. >>> >>> However, in one particular case it's not clear _which_ EUI-64 to >>> use? >>> >>> A Router has two interfaces - two such EUI-64. The ULA prefix >>> which is PIO (Prefix Information Option) on one interface is RIO on >>> the other interface. >>> >>> Which EUI-64 to use? >> >> Why do you think it matters? > > Because if not then everyone would use the same? (hence more risk of > collision?) My question was: Why do you think it matters which of your router's two interfaces you use? Not: Why do you think it matters that you use a real MAC address to generate a ULA prefix? 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 alexandru.petrescu@gmail.com Fri Apr 12 09:55:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8DA21F85DA for ; Fri, 12 Apr 2013 09:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANZvwmiEim7F for ; Fri, 12 Apr 2013 09:55:49 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id DC67221F85A1 for ; Fri, 12 Apr 2013 09:55:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r3CGtjA1024979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 12 Apr 2013 18:55:45 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r3CGti6H020397 for ; Fri, 12 Apr 2013 18:55:45 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.4]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r3CGtWui017934 for ; Fri, 12 Apr 2013 18:55:44 +0200 Message-ID: <51683C84.1070709@gmail.com> Date: Fri, 12 Apr 2013 18:55:32 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: v6ops@ietf.org References: <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <51681DE3.1060407@gmail.com> <51682690.4040809@gmail.com> <5168279A.8030704@gmail.com> <516829B5.40304@viagenie.ca> <51682BEA.2080802@gmail.com> <5168369A.7090504@viagenie.ca> In-Reply-To: <5168369A.7090504@viagenie.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 16:55:50 -0000 Le 12/04/2013 18:30, Simon Perreault a écrit : > Le 2013-04-12 17:44, Alexandru Petrescu a écrit : >> Le 12/04/2013 17:35, Simon Perreault a écrit : >>> Le 2013-04-12 17:26, Alexandru Petrescu a écrit : >>>> Le 12/04/2013 17:21, Brian E Carpenter a écrit : >>>>> On 12/04/2013 15:44, Alexandru Petrescu wrote: ... >>>>>> With respect to ULAs, the prefix we've put in the PIO is a >>>>>> ULA. We used the prefix fd00:f00d:1::/64; that has 'food' >>>>>> because we have a hard time to generate a random and >>>>>> syntactically correct prefix. >>>>> >>>>> Really? http://www.sixxs.net/tools/grh/ula/ >>>> >>>> That GUI may be helpful. It is a good starting point, we will >>>> try to use it in general. >>>> >>>> However, in one particular case it's not clear _which_ EUI-64 >>>> to use? >>>> >>>> A Router has two interfaces - two such EUI-64. The ULA prefix >>>> which is PIO (Prefix Information Option) on one interface is >>>> RIO on the other interface. >>>> >>>> Which EUI-64 to use? >>> >>> Why do you think it matters? >> >> Because if not then everyone would use the same? (hence more risk >> of collision?) > > My question was: Why do you think it matters which of your router's > two interfaces you use? In that sense - I think it does not matter. Any one of the two would do. And actually any third, in oui.txt, like f0:02:2b:f0:00:0d, which is not any of my router's interface - would do as well. (why should I bother revealing a real MAC address when I could just pick someone else's out of oui.txt) (also, my Router may not have any MAC address, at which point I should pick someone's MAC address) The algorithm would generate uniqueness, but maybe less so when preferences shape up for some particular MAC addresses picked out of oui.txt. Or until oui.txt space runs out. > Not: Why do you think it matters that you use a real MAC address to > generate a ULA prefix? Ok. Alex > > Simon From owen@delong.com Fri Apr 12 11:31:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0377D21F8D7A for ; Fri, 12 Apr 2013 11:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fap78CdlJrMw for ; Fri, 12 Apr 2013 11:31:17 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4430221F8D4E for ; Fri, 12 Apr 2013 11:31:16 -0700 (PDT) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r3CIQPRb014381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Apr 2013 11:26:25 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r3CIQPRb014381 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1365791185; bh=uAhtSYpyIxgySqe99KPDOkRLc6M=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IjAV7C+/1FHL92XPluMUg5Z86tEWmteQPi2yCfVMgYrNeZgWrOrXwCyq5t0kvxmLL 1aJ2eCyquBOcvOmVOLLQK38xp2jGEwL7uTfDfEkKvBOav01YJA3nTEqv/nEdBMtsIi XUxhRi23KpJphEpMmSEG9u6hXlzlDd5F658gKqr0= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5168279A.8030704@gmail.com> Date: Fri, 12 Apr 2013 11:26:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <83BF2D9C-94E2-4504-9B0D-0A22221A9DD8@delong.com> References: <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <51681DE3.1060407@gmail.com> <51682690.4040809@gmail.com> <5168279A.8030704@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 12 Apr 2013 11:26:25 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 18:31:18 -0000 On Apr 12, 2013, at 08:26 , Alexandru Petrescu = wrote: > Le 12/04/2013 17:21, Brian E Carpenter a =E9crit : >> On 12/04/2013 15:44, Alexandru Petrescu wrote: ... >>> With respect to ULAs, the prefix we've put in the PIO is a ULA. We >>> used the prefix fd00:f00d:1::/64; that has 'food' because we have a >>> hard time to generate a random and syntactically correct prefix. >>=20 >> Really? http://www.sixxs.net/tools/grh/ula/ >=20 > That GUI may be helpful. It is a good starting point, we will try to > use it in general. >=20 > However, in one particular case it's not clear _which_ EUI-64 to use? >=20 > A Router has two interfaces - two such EUI-64. The ULA prefix which = is > PIO (Prefix Information Option) on one interface is RIO on the other > interface. >=20 > Which EUI-64 to use? IT DOESN'T MATTER. Pick one and just use it. Either one will work just = fine. Owen >=20 > Alex >=20 >=20 >>=20 >> Brian >>=20 >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From marka@isc.org Fri Apr 12 15:09:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B0A21F8EFD for ; Fri, 12 Apr 2013 15:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejjBSn06KtOc for ; Fri, 12 Apr 2013 15:09:31 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5FC21F8ED6 for ; Fri, 12 Apr 2013 15:09:31 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id C20655F98FA; Fri, 12 Apr 2013 22:09:20 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1365804570; bh=GxfAqUfyc+faLTAlNoxUEWFfryBfE4zHfQkJhHJMI2I=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ipy8hsNvMPai1iv2yz8Xj0pve/JIQaZPYcoMucjB0xCCFlGnjmKZk430Us6XZSF0w gFp6GC24zBLaOeTREndA6YpkT0hyvTDK207h+fVmWMtvr6oROnX5jpjfIsk90Ct7Hz O2yKsAvKXBJs/Yi9nL2eqRc3pAKik/lA5HH7b+xc= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:8d92:c49e:ccec:b255]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A356A216C3B; Fri, 12 Apr 2013 22:09:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id DFE58325C866; Sat, 13 Apr 2013 08:09:10 +1000 (EST) To: Owen DeLong From: Mark Andrews References: <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <51681DE3.1060407@gmail.com> <51682690.4040809@gmail.com> <5168279A.8030704@gmail.com> <83BF2D9 C-94E2-4504-9B0D-0A22221A9DD8@delong.com> In-reply-to: Your message of "Fri, 12 Apr 2013 11:26:28 -0700." <83BF2D9C-94E2-4504-9B0D-0A22221A9DD8@delong.com> Date: Sat, 13 Apr 2013 08:09:10 +1000 Message-Id: <20130412220910.DFE58325C866@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 22:09:32 -0000 In message <83BF2D9C-94E2-4504-9B0D-0A22221A9DD8@delong.com>, Owen DeLong write s: > > On Apr 12, 2013, at 08:26 , Alexandru Petrescu m> wrote: > > > Le 12/04/2013 17:21, Brian E Carpenter a =E9crit : > >> On 12/04/2013 15:44, Alexandru Petrescu wrote: ... > >>> With respect to ULAs, the prefix we've put in the PIO is a ULA. We > >>> used the prefix fd00:f00d:1::/64; that has 'food' because we have a > >>> hard time to generate a random and syntactically correct prefix. > >> = > > >> Really? http://www.sixxs.net/tools/grh/ula/ > > = > > > That GUI may be helpful. It is a good starting point, we will try to > > use it in general. > > = > > > However, in one particular case it's not clear _which_ EUI-64 to use? > > = > > > A Router has two interfaces - two such EUI-64. The ULA prefix which is > > PIO (Prefix Information Option) on one interface is RIO on the other > > interface. > > = > > > Which EUI-64 to use? > > IT DOESN'T MATTER. Pick one and just use it. Either one will work just fine. > > Owen Additionally *ANY* source of truly random numbers will do (RFC 4193, Section 3.2.1. Locally Assigned Global IDs). If your /dev/random generates truly random values then the following will do. dd if=/dev/random bs=5 count=1 | od -tx1 % dd if=/dev/random bs=5 count=1 | od -tx1 1+0 records in 1+0 records out 5 bytes transferred in 0.000051 secs (97998 bytes/sec) 0000000 83 d1 17 05 7f 0000005 % Which would result in fd83:d117:057f. Flip a coin 40 times (heads 1, tails 0) and use the resulting bit pattern. Don't just choose a value. Go to the effort of generating the bits from a random source. The algorithm in RFC4193 Section 3.2.2. is written for the case where the CPE *does not* have a good source of randomness but does have a clock or just trusts its ntp source and a unique identifier (MAC). > > = > > > Alex > > = > > > = > > >> = > > >> Brian > >> = > > >> = > > > = > > > = > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From alexandru.petrescu@gmail.com Sat Apr 13 14:11:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B36021F8C06 for ; Sat, 13 Apr 2013 14:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.863 X-Spam-Level: X-Spam-Status: No, score=-9.863 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJHkMa8OkWgI for ; Sat, 13 Apr 2013 14:11:18 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id F3B7521F8B49 for ; Sat, 13 Apr 2013 14:11:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r3DLBCfs004391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Apr 2013 23:11:12 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r3DLBBH0007022; Sat, 13 Apr 2013 23:11:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r3DLBAql016703; Sat, 13 Apr 2013 23:11:11 +0200 Message-ID: <5169C9EE.1060506@gmail.com> Date: Sat, 13 Apr 2013 23:11:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mark Andrews References: <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <51681DE3.1060407@gmail.com> <51682690.4040809@gmail.com> <5168279A.8030704@gmail.com> <83BF2D9 C-94E2-4504-9B0D-0A22221A9DD8@delong.com> <20130412220910.DFE58325C866@drugs.dv.isc.org> In-Reply-To: <20130412220910.DFE58325C866@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 21:11:19 -0000 Mark - yes; thanks for the /dev/random command to generate ULA prefix without EUI-64. It makes sense. It's not documented. Not sure whether it needs to be documented. But this rfc4191 implementation report was more geared towards the dhcp-route discussion, and less about ULA. I will have to refromulate separately. Alex Le 13/04/2013 00:09, Mark Andrews a écrit : > > In message <83BF2D9C-94E2-4504-9B0D-0A22221A9DD8@delong.com>, Owen DeLong write > s: >> >> On Apr 12, 2013, at 08:26 , Alexandru Petrescu > m> wrote: >> >>> Le 12/04/2013 17:21, Brian E Carpenter a =E9crit : >>>> On 12/04/2013 15:44, Alexandru Petrescu wrote: ... >>>>> With respect to ULAs, the prefix we've put in the PIO is a ULA. We >>>>> used the prefix fd00:f00d:1::/64; that has 'food' because we have a >>>>> hard time to generate a random and syntactically correct prefix. >>>> = >> >>>> Really? http://www.sixxs.net/tools/grh/ula/ >>> = >> >>> That GUI may be helpful. It is a good starting point, we will try to >>> use it in general. >>> = >> >>> However, in one particular case it's not clear _which_ EUI-64 to use? >>> = >> >>> A Router has two interfaces - two such EUI-64. The ULA prefix which is >>> PIO (Prefix Information Option) on one interface is RIO on the other >>> interface. >>> = >> >>> Which EUI-64 to use? >> >> IT DOESN'T MATTER. Pick one and just use it. Either one will work just fine. >> >> Owen > > Additionally *ANY* source of truly random numbers will do (RFC 4193, > Section 3.2.1. Locally Assigned Global IDs). If your /dev/random > generates truly random values then the following will do. > > dd if=/dev/random bs=5 count=1 | od -tx1 > > % dd if=/dev/random bs=5 count=1 | od -tx1 > 1+0 records in > 1+0 records out > 5 bytes transferred in 0.000051 secs (97998 bytes/sec) > 0000000 83 d1 17 05 7f > 0000005 > % > > Which would result in fd83:d117:057f. > > Flip a coin 40 times (heads 1, tails 0) and use the resulting bit > pattern. > > Don't just choose a value. Go to the effort of generating the bits > from a random source. > > The algorithm in RFC4193 Section 3.2.2. is written for the case > where the CPE *does not* have a good source of randomness but does > have a clock or just trusts its ntp source and a unique identifier > (MAC). > >>> = >> >>> Alex >>> = >> >>> = >> >>>> = >> >>>> Brian >>>> = >> >>>> = >> >>> = >> >>> = >> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Sat Apr 13 14:14:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F7D21F8614 for ; Sat, 13 Apr 2013 14:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.136 X-Spam-Level: X-Spam-Status: No, score=-10.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9g5xpvRZ9r2a for ; Sat, 13 Apr 2013 14:14:58 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 500CF21F86C1 for ; Sat, 13 Apr 2013 14:14:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r3DLErFx030155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 13 Apr 2013 23:14:53 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r3DLErXO007398 for ; Sat, 13 Apr 2013 23:14:53 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r3DLEqoE017232 for ; Sat, 13 Apr 2013 23:14:53 +0200 Message-ID: <5169CACC.2030805@gmail.com> Date: Sat, 13 Apr 2013 23:14:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> \015 <20130327163318.GA10704@spike.0x539.de> <20130330110545.GA29987@spike.0x539.de> <8D23D4052ABE7A4490E77B1A012B630775127F3E@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775127F3E@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 21:14:59 -0000 We had discussion about interest in DHCPv6 Route/DefRouter/src-basedRoute configuration to Client. During that discussion one question was raised about RFC4191 "default route preferences and more specific routes" implementation status. I reported that in linux there is implementation ok about this, with a certain degree of maturity. I wonder what does that mean with respect to: - are there other non-linux implementaitons of rfc4191. - any effect of this on the alternative way of doing it with DHCP. Alex From tjc@ecs.soton.ac.uk Sat Apr 13 17:03:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F7321F8D14 for ; Sat, 13 Apr 2013 17:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIbjdPCcmxGk for ; Sat, 13 Apr 2013 17:03:00 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 06F3721F8546 for ; Sat, 13 Apr 2013 17:02:59 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r3E02rf3032121 for ; Sun, 14 Apr 2013 01:02:53 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r3E02rf3032121 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1365897773; bh=EyRrf5Nz424SYzK3isIvX3N3gWQ=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=cBxlMhuMA4VEea27FsySSue7g8+smJ3CHqrmVe8d7e2ZtqtU4xm+5fLP4IN6yEMZF MKfPKk2qSib6E2BwsnOOKajEgkbG2ImYNfqEukYK70qLvYsSxF0hjT3U1qv4BQB4Qx +NWkUE9JApsM28jPlWnXimJ2Tl7MKQWVhb5INUz0= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p3D12r0430637781FP ret-id none; Sun, 14 Apr 2013 01:02:53 +0100 Received: from [192.168.1.110] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r3E01VOt022063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 14 Apr 2013 01:01:31 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_62DF2C45-30A1-41C1-B4E7-D1E144846FDB" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Sun, 14 Apr 2013 01:01:31 +0100 References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> <95685740-6854-4C76-9336-7867DE4C3D96@ecs.soton.ac.uk> To: v6ops v6ops WG In-Reply-To: <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p3D12r043063778100; tid=p3D12r0430637781FP; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r3E02rf3032121 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 00:03:04 -0000 --Apple-Mail=_62DF2C45-30A1-41C1-B4E7-D1E144846FDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 28 Mar 2013, at 08:06, Mark Smith wrote: > The only way to record all addresses in use on an segment is to = observe neighbor discovery messages, primarily DADs, and once learned, = actively probe them using methods similar to NUD to detect when they = disappear. If that is still not acceptable, then admission control via = e.g. 802.1x, and then isolating authorised clients in their own virtual = point-to-point link with the router (e.g. individual VLAN with = individual /64) would be the way to control who attaches to the network, = and what they can reach. Or by querying your switch/router equipment for IP/MAC data, e.g. = https://nav.uninett.no/, which can be part of your mainstream network = monitoring tools (and integrate IPv4 and IPv6 cleanly if dual-stack). Tim= --Apple-Mail=_62DF2C45-30A1-41C1-B4E7-D1E144846FDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 markzzzsmith@yahoo.com.au>= ; wrote:
The only way to record all = addresses in use on an segment is to observe neighbor discovery = messages, primarily DADs, and once learned, actively probe them using = methods similar to NUD to detect when they disappear. If that is still = not acceptable, then admission control via e.g. 802.1x, and then = isolating authorised clients in their own virtual point-to-point link = with the router (e.g. individual VLAN with individual /64) would be the = way to control who attaches to the network, and what they can = reach.

Or by querying your switch/router = equipment for IP/MAC data, e.g. https://nav.uninett.no/, which can = be part of your mainstream network monitoring tools (and integrate IPv4 = and IPv6 cleanly if = dual-stack).

Tim
= --Apple-Mail=_62DF2C45-30A1-41C1-B4E7-D1E144846FDB-- From fred@cisco.com Tue Apr 16 07:42:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B50121F9748 for ; Tue, 16 Apr 2013 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTG3sU3uBLBi for ; Tue, 16 Apr 2013 07:42:28 -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 A98AF21F9747 for ; Tue, 16 Apr 2013 07:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=163; q=dns/txt; s=iport; t=1366123348; x=1367332948; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=PjRQnVIZfh0XmrBTK1ZTaT5MuUkBn2pRKcLpRdUOa0c=; b=c1zYb9BUFSNbMiIwtaB23L5ipFg43wE48NjRxkxpuzVC3zsMws7m4sgh bXVIV1Z9biZfjMPZmhpmchJl1u+V1BCYwIorz+ryiaoYY/yd7LnyrMej9 0T0tGDxdLK7Q6Zct3hMMXeg2PO9zpw64df9n4gajtcpB7fe8jRXM++wSd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFALhhbVGtJXG//2dsb2JhbABQgwbBPIEJFnSCIQEEOj8SASoUQicEDg2IDKxpkEmOXjGCaGEDqBmDC4Io X-IronPort-AV: E=Sophos;i="4.87,486,1363132800"; d="scan'208";a="199358489" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 16 Apr 2013 14:42:28 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3GEgR3Q003453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Apr 2013 14:42:27 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 16 Apr 2013 09:42:27 -0500 From: "Fred Baker (fred)" To: v6ops WG Thread-Topic: draft-ietf-v6ops-64share Thread-Index: AQHOOrCdqggbPVHllkiVUXjOTX0+RA== Date: Tue, 16 Apr 2013 14:42:26 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B8109E4@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.136.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <0D587BE366B8C040B6543A06D828CD7E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 14:42:29 -0000 The authors have updated this draft in response to the discussion at IETF 8= 5 and 86. I'd appreciate folks that commented on it reviewing it prior to W= GLC.= From swmike@swm.pp.se Wed Apr 17 03:23:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E291721F8D46 for ; Wed, 17 Apr 2013 03:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhfJiZZjG5Vd for ; Wed, 17 Apr 2013 03:23:33 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3971621F8BAE for ; Wed, 17 Apr 2013 03:23:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8F3EE9C; Wed, 17 Apr 2013 12:23:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8825A9A for ; Wed, 17 Apr 2013 12:23:21 +0200 (CEST) Date: Wed, 17 Apr 2013 12:23:21 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 10:23:36 -0000 Hello. I would like to solicit some feedback on a deployment scenario. A device has dual stack access on its WAN access, with IPv4 RFC1918 addresses or 100.64.0.0/10 address space on WAN side, and a CGN NAT44 gateway for sharing these addresses towards the Internet, and GUA IPv6 addresses. There is also a NAT64 gateway in the network, and a DNS64 resolver reachable over IPv6. There is a regular resolver reachable over IPv4. A dual stack client will get both types of resolvers. Now, aim is to support all kinds of devices, IPv4 only, IPv6 only, and dual stack. The single stack cases are pretty obvious (IPv4 single stack will use NAT44, IPv6 single stack will use NAT64/DNS64 and require 464XLAT for "proper" function), but my question relates to the dual stack case. With a DNS64 based resolver, only IPv4 literals will go over the NAT44, if the device uses the IPv6 based resolver. If it uses the IPv4 based resolver, it will use the NAT44 device for IPv4 only sites. So my questions are: 1. Is there a case where the above setup will cause problems? 2. Does it make sense to turn on DNS64 even on the IPv4 based resolver? This would cause AAAA lookups over IPv4 to steer traffic towards the NAT64 gateway, in case a client chooses to use the IPv4 based resolver for lookups even if it's dual stacked. As far as I understand, a DNS64 based resolver will forward A quaries unmodified so this shouldn't cause any problems for single stacked IPv4 clients? 3. Did I miss anything? -- Mikael Abrahamsson email: swmike@swm.pp.se From mohamed.boucadair@orange.com Wed Apr 17 04:20:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381DA21F8D82 for ; Wed, 17 Apr 2013 04:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioG2CNkLhNwa for ; Wed, 17 Apr 2013 04:20:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EC6F421F8D40 for ; Wed, 17 Apr 2013 04:20:44 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1A6E118C554; Wed, 17 Apr 2013 13:20:43 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id F284D4C017; Wed, 17 Apr 2013 13:20:42 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 17 Apr 2013 13:20:42 +0200 From: To: Mikael Abrahamsson , "v6ops@ietf.org" Date: Wed, 17 Apr 2013 13:20:41 +0200 Thread-Topic: [v6ops] combination of NAT64/DNS64 and NAT44 Thread-Index: Ac47Vbd5saIub3dVR1Gx3IyHKJrZSwABtDwA Message-ID: <94C682931C08B048B7A8645303FDC9F36EC66217D9@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Cc: "Tirumaleswar Reddy \(tireddy\) \(tireddy@cisco.com\)" Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 11:20:46 -0000 Hi Mikael, Isn't your problem similar to what is discussed here: http://tools.ietf.org= /html/draft-kaliwoda-sunset4-dual-ipv6-coexist-01? This problem is also discussed at: http://tools.ietf.org/html/draft-wing-dh= c-dns-reconfigure-00 Cheers, Med >-----Message d'origine----- >De=A0: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part d= e >Mikael Abrahamsson >Envoy=E9=A0: mercredi 17 avril 2013 12:23 >=C0=A0: v6ops@ietf.org >Objet=A0: [v6ops] combination of NAT64/DNS64 and NAT44 > > >Hello. > >I would like to solicit some feedback on a deployment scenario. > >A device has dual stack access on its WAN access, with IPv4 RFC1918 >addresses or 100.64.0.0/10 address space on WAN side, and a CGN NAT44 >gateway for sharing these addresses towards the Internet, and GUA IPv6 >addresses. There is also a NAT64 gateway in the network, and a DNS64 >resolver reachable over IPv6. There is a regular resolver reachable over >IPv4. A dual stack client will get both types of resolvers. > >Now, aim is to support all kinds of devices, IPv4 only, IPv6 only, and >dual stack. The single stack cases are pretty obvious (IPv4 single stack >will use NAT44, IPv6 single stack will use NAT64/DNS64 and require 464XLAT >for "proper" function), but my question relates to the dual stack case. >With a DNS64 based resolver, only IPv4 literals will go over the NAT44, if >the device uses the IPv6 based resolver. If it uses the IPv4 based >resolver, it will use the NAT44 device for IPv4 only sites. > >So my questions are: > >1. Is there a case where the above setup will cause problems? > >2. Does it make sense to turn on DNS64 even on the IPv4 based resolver? >This would cause AAAA lookups over IPv4 to steer traffic towards the NAT64 >gateway, in case a client chooses to use the IPv4 based resolver for >lookups even if it's dual stacked. As far as I understand, a DNS64 based >resolver will forward A quaries unmodified so this shouldn't cause any >problems for single stacked IPv4 clients? > >3. Did I miss anything? > >-- >Mikael Abrahamsson email: swmike@swm.pp.se >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Wed Apr 17 07:31:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8B221E8048 for ; Wed, 17 Apr 2013 07:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5wU4FTDolzl for ; Wed, 17 Apr 2013 07:31:58 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 07B4B21F8A6B for ; Wed, 17 Apr 2013 07:31:53 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C58CF9C; Wed, 17 Apr 2013 16:31:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C0C859A; Wed, 17 Apr 2013 16:31:52 +0200 (CEST) Date: Wed, 17 Apr 2013 16:31:52 +0200 (CEST) From: Mikael Abrahamsson To: mohamed.boucadair@orange.com In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC66217D9@PUEXCB1B.nanterre.francetelecom.fr> Message-ID: References: <94C682931C08B048B7A8645303FDC9F36EC66217D9@PUEXCB1B.nanterre.francetelecom.fr> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , "Tirumaleswar Reddy \(tireddy\) \(tireddy@cisco.com\)" Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 14:31:59 -0000 On Wed, 17 Apr 2013, mohamed.boucadair@orange.com wrote: > Isn't your problem similar to what is discussed here: > http://tools.ietf.org/html/draft-kaliwoda-sunset4-dual-ipv6-coexist-01? Well, partly. > This problem is also discussed at: http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-00 Yes, but my network (3GPP based) doesn't use DHCPv6 to hand out IPv6 DNS resolvers, so unfortunately this doesn't help me. -- Mikael Abrahamsson email: swmike@swm.pp.se From simon.perreault@viagenie.ca Wed Apr 17 07:43:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0522021E803D for ; Wed, 17 Apr 2013 07:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtORSDRBVuaO for ; Wed, 17 Apr 2013 07:43:25 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7D321F8550 for ; Wed, 17 Apr 2013 07:43:25 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:a0bf:2ff:321b:e17b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A9FA040401 for ; Wed, 17 Apr 2013 10:42:54 -0400 (EDT) Message-ID: <516EB4EC.7010102@viagenie.ca> Date: Wed, 17 Apr 2013 16:42:52 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 14:43:26 -0000 Le 2013-04-17 12:23, Mikael Abrahamsson a écrit : > A device has dual stack access on its WAN access, with IPv4 RFC1918 > addresses or 100.64.0.0/10 address space on WAN side, and a CGN NAT44 > gateway for sharing these addresses towards the Internet, and GUA IPv6 > addresses. There is also a NAT64 gateway in the network, and a DNS64 > resolver reachable over IPv6. There is a regular resolver reachable over > IPv4. A dual stack client will get both types of resolvers. > > Now, aim is to support all kinds of devices, IPv4 only, IPv6 only, and > dual stack. The single stack cases are pretty obvious (IPv4 single stack > will use NAT44, IPv6 single stack will use NAT64/DNS64 and require > 464XLAT for "proper" function), but my question relates to the dual > stack case. With a DNS64 based resolver, only IPv4 literals will go over > the NAT44, if the device uses the IPv6 based resolver. This is not quite true. Happy-eyeballs algorithms will direct some traffic over IPv4 even if IPv6 is available. It could even be a lot of traffic, or even most traffic, depending on traffic patterns. > If it uses the > IPv4 based resolver, it will use the NAT44 device for IPv4 only sites. > > So my questions are: > > 1. Is there a case where the above setup will cause problems? It should work, but it will not be fun to operate. > 2. Does it make sense to turn on DNS64 even on the IPv4 based resolver? > This would cause AAAA lookups over IPv4 to steer traffic towards the > NAT64 gateway, in case a client chooses to use the IPv4 based resolver > for lookups even if it's dual stacked. As far as I understand, a DNS64 > based resolver will forward A quaries unmodified so this shouldn't cause > any problems for single stacked IPv4 clients? It makes a lot of sense, especially since some implementations do happy eyeballs at the DNS level and cache the first result received. So an otherwise perfectly dual stack node might end up not using the NAT64 if it happens to obtain results from the IPv4 resolver first and that resolver doesn't do DNS64. > 3. Did I miss anything? It might not be immediately useful to you, but you should know about this draft: https://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic Other than that, my main feedback would be: you want to provide NATed IPv4 alongside NAT64, doesn't that defeat the purpose of NAT64, i.e. operating an IPv6-only network? Simon From swmike@swm.pp.se Wed Apr 17 07:48:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C3421E803F for ; Wed, 17 Apr 2013 07:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG+d7PkufGKN for ; Wed, 17 Apr 2013 07:48:43 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C518721E803D for ; Wed, 17 Apr 2013 07:48:42 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1BC789E; Wed, 17 Apr 2013 16:48:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 13F159A; Wed, 17 Apr 2013 16:48:42 +0200 (CEST) Date: Wed, 17 Apr 2013 16:48:42 +0200 (CEST) From: Mikael Abrahamsson To: Simon Perreault In-Reply-To: <516EB4EC.7010102@viagenie.ca> Message-ID: References: <516EB4EC.7010102@viagenie.ca> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 14:48:43 -0000 On Wed, 17 Apr 2013, Simon Perreault wrote: > It might not be immediately useful to you, but you should know about this > draft: > https://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic Yep. Also RFC6877, but my guess would be that the 464XLAT would be disabled when WAN port is dual stack? > Other than that, my main feedback would be: you want to provide NATed > IPv4 alongside NAT64, doesn't that defeat the purpose of NAT64, i.e. > operating an IPv6-only network? I want all kinds of terminals to be supported using single APN. I don't want to care if the device connects using DS or single stack IPv4 or IPv6. I don't control the end devices. -- Mikael Abrahamsson email: swmike@swm.pp.se From cb.list6@gmail.com Wed Apr 17 07:54:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1649721F870F for ; Wed, 17 Apr 2013 07:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlcH2WdNHI0g for ; Wed, 17 Apr 2013 07:54:21 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 01F5521F8C4F for ; Wed, 17 Apr 2013 07:54:20 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id c11so1685003wgh.10 for ; Wed, 17 Apr 2013 07:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WP/HPCG+6eG4OLqEI8AeKX3/IYobsSdCrnBl/u1U8Wg=; b=e1gKdnvuuWdxzstVHRwks9wQF6lV4/mN/pDFyJq9RxzHi45sQlfPA7zhpjvZjFikN4 NgHpO4IlzHXyDqarnDpQ6nSfhbryYA95UNX1/mhTR0JsrJrPJ5h26fjOD03XcxKOx7vp /JhxixsAFbtl0PxaYkrhomIAvOgoWEZQWTqYOmE/k4eRsGGCTd6IEbvUjuCHtF8UOGOj 48Xj+x6lHb6Mea9YzIqnzMx4lVYzXYIIHe93ch9jEPlU6b39m7d0Y00xqf+/tcTKrObg I1wPt5+6fg2WkP8NAr8+Zrd8L2z1oM6xk3GOONpHP54G4alB12libKj3lphZA0rnOhhI aIvQ== MIME-Version: 1.0 X-Received: by 10.180.72.228 with SMTP id g4mr27048801wiv.22.1366210460227; Wed, 17 Apr 2013 07:54:20 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Wed, 17 Apr 2013 07:54:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Apr 2013 07:54:20 -0700 Message-ID: From: "cb.list6" To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 14:54:22 -0000 On Wed, Apr 17, 2013 at 3:23 AM, Mikael Abrahamsson wrote: > > Hello. > > I would like to solicit some feedback on a deployment scenario. > > A device has dual stack access on its WAN access, with IPv4 RFC1918 > addresses or 100.64.0.0/10 address space on WAN side, and a CGN NAT44 > gateway for sharing these addresses towards the Internet, and GUA IPv6 > addresses. There is also a NAT64 gateway in the network, and a DNS64 > resolver reachable over IPv6. There is a regular resolver reachable over > IPv4. A dual stack client will get both types of resolvers. > > Now, aim is to support all kinds of devices, IPv4 only, IPv6 only, and dual > stack. The single stack cases are pretty obvious (IPv4 single stack will use > NAT44, IPv6 single stack will use NAT64/DNS64 and require 464XLAT for > "proper" function), but my question relates to the dual stack case. With a > DNS64 based resolver, only IPv4 literals will go over the NAT44, if the > device uses the IPv6 based resolver. If it uses the IPv4 based resolver, it > will use the NAT44 device for IPv4 only sites. > > So my questions are: > > 1. Is there a case where the above setup will cause problems? > > 2. Does it make sense to turn on DNS64 even on the IPv4 based resolver? This > would cause AAAA lookups over IPv4 to steer traffic towards the NAT64 > gateway, in case a client chooses to use the IPv4 based resolver for lookups > even if it's dual stacked. As far as I understand, a DNS64 based resolver > will forward A quaries unmodified so this shouldn't cause any problems for > single stacked IPv4 clients? > > 3. Did I miss anything? > i already operate this way. I don't really see a major downsides. Depending on how you want to deploy, you can leverage RFC 6724 in different ways with either a GUA or ULA pref64. Meaning, RFC6724 prefers any IPv4 over ULA. And, if your pref64 is ULA, the dual-stack devices in your network will always use NAT44 if they have IPv4, since ULA is a lower pref. But, ULA Pref64 has some impacts on 464XLAT / RFC 6877. If you are trying to optimize for single translation since anything that is not native IPv6 will have translation at the CLAT and PLAT, but that is acceptable in many scenarios. CB > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From simon.perreault@viagenie.ca Wed Apr 17 07:55:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAE321E8050 for ; Wed, 17 Apr 2013 07:55: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qeokZWbYkdh for ; Wed, 17 Apr 2013 07:55:38 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D453F21E8047 for ; Wed, 17 Apr 2013 07:55:37 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:a0bf:2ff:321b:e17b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1192E40401; Wed, 17 Apr 2013 10:55:36 -0400 (EDT) Message-ID: <516EB7E9.6050805@viagenie.ca> Date: Wed, 17 Apr 2013 16:55:37 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mikael Abrahamsson References: <516EB4EC.7010102@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 14:55:38 -0000 Le 2013-04-17 16:48, Mikael Abrahamsson a écrit : >> Other than that, my main feedback would be: you want to provide NATed >> IPv4 alongside NAT64, doesn't that defeat the purpose of NAT64, i.e. >> operating an IPv6-only network? > > I want all kinds of terminals to be supported using single APN. I don't > want to care if the device connects using DS or single stack IPv4 or IPv6. IMHO, it would be better engineering-wise to provision different sets of parameters for DS, SSv4, and SSv6. DS: IPv6 + NAT44 SSv4: NAT44 SSv6: IPv6 + NAT64 And you're lucky, you can even determine the kind of client based on the PDP type. Others aren't so lucky... ;) Can you do that using a single APN? Simon From Michal.Czerwonka1@orange.com Wed Apr 17 08:14:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8034021F8A85 for ; Wed, 17 Apr 2013 08:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.386 X-Spam-Level: * X-Spam-Status: No, score=1.386 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFUOD1Mb4BjX for ; Wed, 17 Apr 2013 08:14:47 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDAC21F8A80 for ; Wed, 17 Apr 2013 08:14:46 -0700 (PDT) Received: from 10.236.62.137 (EHLO OPE10HT03.tp.gk.corp.tepenet) ([10.236.62.137]) by mailin.tpsa.pl (MOS 3.10.10a-GA FastPath queued) with ESMTP id BBB91886; Wed, 17 Apr 2013 17:14:45 +0200 (CEST) From: =?iso-8859-2?Q?Czerwonka_Micha=B3_-_Hurt_TP?= To: "v6ops@ietf.org" Thread-Topic: [v6ops] combination of NAT64/DNS64 and NAT44 Thread-Index: AQHOO1WoAkc82BAeekuNHf3rK4G4uZjaW3sAgAABoQCAAAHvgIAAJHIg Date: Wed, 17 Apr 2013 15:14:44 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745EF876C@OPE10MB03.tp.gk.corp.tepenet> References: <516EB4EC.7010102@viagenie.ca> <516EB7E9.6050805@viagenie.ca> In-Reply-To: <516EB7E9.6050805@viagenie.ca> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0C0206.516EBC65.0184,ss=1,fgs=0, ip=10.236.62.137, so=2010-07-09 01:15:44, dmn=5.4.3/2007-10-18, mode=single engine X-Junkmail-IWF: false X-Mirapoint-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0206.516EBC65.0184,ss=1,fgs=0, ip=10.236.62.137, so=2010-07-09 01:15:44, dmn=5.4.3/2007-10-18 X-Mirapoint-Loop-Id: 9e44ae6a310f659752c913e1088619b5 Subject: [v6ops] ODP: combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 15:14:48 -0000 Or=20 SSv4: NAT44 + DNS_DS (old UE or new) SSv6: IPv6 + NAT64 + DNS64_DS ( new samrtphones/routers/tablets with CLAT f= eature) DS will be if enduser establish two PDP at the same time (dongles) (of cour= ce if network allowed this) DNS_DS !=3D DNS64_DS BR, Mcz -----Wiadomo=B6=E6 oryginalna----- Od: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] W imieniu Simon = Perreault Wys=B3ano: 17 kwietnia 2013 16:56 Do: Mikael Abrahamsson DW: v6ops@ietf.org Temat: Re: [v6ops] combination of NAT64/DNS64 and NAT44 Le 2013-04-17 16:48, Mikael Abrahamsson a =E9crit : >> Other than that, my main feedback would be: you want to provide NATed >> IPv4 alongside NAT64, doesn't that defeat the purpose of NAT64, i.e. >> operating an IPv6-only network? > > I want all kinds of terminals to be supported using single APN. I don't > want to care if the device connects using DS or single stack IPv4 or IPv6= . IMHO, it would be better engineering-wise to provision different sets of=20 parameters for DS, SSv4, and SSv6. DS: IPv6 + NAT44 SSv4: NAT44 SSv6: IPv6 + NAT64 And you're lucky, you can even determine the kind of client based on the=20 PDP type. Others aren't so lucky... ;) Can you do that using a single APN? Simon _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From sarikaya2012@gmail.com Wed Apr 17 08:43:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C6C21F86C3 for ; Wed, 17 Apr 2013 08:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdyevrWvmByg for ; Wed, 17 Apr 2013 08:43:24 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4016921F867B for ; Wed, 17 Apr 2013 08:43:24 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id t1so1767192lbd.38 for ; Wed, 17 Apr 2013 08:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3wCKSrjdgcvkJUdqh81kwo8Q8Toh1wZzHd4TUOH9+7o=; b=g+JpfiCcgd1g2Xa/M5FCKhjURjWyRPg9xFpeJCFySBg3ZIIC12UJZsf2+JFAYCXkJI jHsbMaHfFvYofVENUosqIRLfyJFSk3GzgMFIPZR6reNfO3RUIh5+d6Zf0C5KiObEIxM0 iOzQ3DzZorY09CXuPcPoxxEclPH+8atEBkvWsI75ZNLQNIJ+i9U3dFvq9TidabHdZIoE Zh8D0+zTo2fydu8DoQdaDL4Oj1iAZc+3WUMGG5h4S6c/j3q0B4/wzQJTwSXZVlgNS6sx yprlCAPfq3L4IAbQjE2S4AmZeYJGBlmvR5r9KRqTUdu4w0r1f8/z3fATcJVCDjJCpY/l LvJw== MIME-Version: 1.0 X-Received: by 10.112.139.102 with SMTP id qx6mr3816359lbb.99.1366213403109; Wed, 17 Apr 2013 08:43:23 -0700 (PDT) Received: by 10.114.175.140 with HTTP; Wed, 17 Apr 2013 08:43:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Apr 2013 10:43:22 -0500 Message-ID: From: Behcet Sarikaya To: "cb.list6" Content-Type: multipart/alternative; boundary=089e01182d48946ec704da9058c5 Cc: IPv6 Ops WG Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 15:43:26 -0000 --089e01182d48946ec704da9058c5 Content-Type: text/plain; charset=ISO-8859-1 Does it make sense to complicate the network with all these things if you have a dual stack network? Is it to discourage people from using IPv4? Or be ready for IPv6 only network? I don't understand. Regards, Behcet On Wed, Apr 17, 2013 at 9:54 AM, cb.list6 wrote: > On Wed, Apr 17, 2013 at 3:23 AM, Mikael Abrahamsson > wrote: > > > > Hello. > > > > I would like to solicit some feedback on a deployment scenario. > > > > A device has dual stack access on its WAN access, with IPv4 RFC1918 > > addresses or 100.64.0.0/10 address space on WAN side, and a CGN NAT44 > > gateway for sharing these addresses towards the Internet, and GUA IPv6 > > addresses. There is also a NAT64 gateway in the network, and a DNS64 > > resolver reachable over IPv6. There is a regular resolver reachable over > > IPv4. A dual stack client will get both types of resolvers. > > > > Now, aim is to support all kinds of devices, IPv4 only, IPv6 only, and > dual > > stack. The single stack cases are pretty obvious (IPv4 single stack will > use > > NAT44, IPv6 single stack will use NAT64/DNS64 and require 464XLAT for > > "proper" function), but my question relates to the dual stack case. With > a > > DNS64 based resolver, only IPv4 literals will go over the NAT44, if the > > device uses the IPv6 based resolver. If it uses the IPv4 based resolver, > it > > will use the NAT44 device for IPv4 only sites. > > > > So my questions are: > > > > 1. Is there a case where the above setup will cause problems? > > > > 2. Does it make sense to turn on DNS64 even on the IPv4 based resolver? > This > > would cause AAAA lookups over IPv4 to steer traffic towards the NAT64 > > gateway, in case a client chooses to use the IPv4 based resolver for > lookups > > even if it's dual stacked. As far as I understand, a DNS64 based resolver > > will forward A quaries unmodified so this shouldn't cause any problems > for > > single stacked IPv4 clients? > > > > 3. Did I miss anything? > > > > i already operate this way. I don't really see a major downsides. > > Depending on how you want to deploy, you can leverage RFC 6724 in > different ways with either a GUA or ULA pref64. Meaning, RFC6724 > prefers any IPv4 over ULA. And, if your pref64 is ULA, the dual-stack > devices in your network will always use NAT44 if they have IPv4, since > ULA is a lower pref. > > But, ULA Pref64 has some impacts on 464XLAT / RFC 6877. If you are > trying to optimize for single translation since anything that is not > native IPv6 will have translation at the CLAT and PLAT, but that is > acceptable in many scenarios. > > > CB > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e01182d48946ec704da9058c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Does it make sense to complicate the network with all these things if you h= ave a dual stack network?

Is it to discourage people from using IPv4= ? Or be ready for IPv6 only network?

I don't understand.

Regards,

Behcet

On Wed, Apr 17, 20= 13 at 9:54 AM, cb.list6 <cb.list6@gmail.com> wrote:
On Wed, Apr 17, 2013 at 3:23 AM, Mi= kael Abrahamsson <swmike@swm.pp.se> wrote:
>
> Hello.
>
> I would like to solicit some feedback on a deployment scenario.
>
> A device has dual stack access on its WAN access, with IPv4 RFC1918 > addresses or 100.64= .0.0/10 address space on WAN side, and a CGN NAT44
> gateway for sharing these addresses towards the Internet, and GUA IPv6=
> addresses. There is also a NAT64 gateway in the network, and a DNS64 > resolver reachable over IPv6. There is a regular resolver reachable ov= er
> IPv4. A dual stack client will get both types of resolvers.
>
> Now, aim is to support all kinds of devices, IPv4 only, IPv6 only, and= dual
> stack. The single stack cases are pretty obvious (IPv4 single stack wi= ll use
> NAT44, IPv6 single stack will use NAT64/DNS64 and require 464XLAT for<= br> > "proper" function), but my question relates to the dual stac= k case. With a
> DNS64 based resolver, only IPv4 literals will go over the NAT44, if th= e
> device uses the IPv6 based resolver. If it uses the IPv4 based resolve= r, it
> will use the NAT44 device for IPv4 only sites.
>
> So my questions are:
>
> 1. Is there a case where the above setup will cause problems?
>
> 2. Does it make sense to turn on DNS64 even on the IPv4 based resolver= ? This
> would cause AAAA lookups over IPv4 to steer traffic towards the NAT64<= br> > gateway, in case a client chooses to use the IPv4 based resolver for l= ookups
> even if it's dual stacked. As far as I understand, a DNS64 based r= esolver
> will forward A quaries unmodified so this shouldn't cause any prob= lems for
> single stacked IPv4 clients?
>
> 3. Did I miss anything?
>

i already operate this way. =A0I don't really see a major d= ownsides.

Depending on how you want to deploy, you can leverage RFC 6724 in
different ways with either a GUA or ULA pref64. =A0Meaning, RFC6724
prefers any IPv4 over ULA. =A0And, if your pref64 is ULA, the dual-stack devices in your network will always use NAT44 if they have IPv4, since
ULA is a lower pref.

But, ULA Pref64 has some impacts on 464XLAT / RFC 6877. =A0If you are
trying to optimize for single translation since anything that is not
native IPv6 will have translation at the CLAT and PLAT, but that is
acceptable in many scenarios.


CB

> --
> Mikael Abrahamsson =A0 =A0email: s= wmike@swm.pp.se
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--089e01182d48946ec704da9058c5-- From swmike@swm.pp.se Wed Apr 17 08:46:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8990B21E8089 for ; Wed, 17 Apr 2013 08:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOyRPtR+HkCW for ; Wed, 17 Apr 2013 08:46:24 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id EC38F21E8049 for ; Wed, 17 Apr 2013 08:46:23 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 67EF09C; Wed, 17 Apr 2013 17:46:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 59E8E9A; Wed, 17 Apr 2013 17:46:21 +0200 (CEST) Date: Wed, 17 Apr 2013 17:46:21 +0200 (CEST) From: Mikael Abrahamsson To: sarikaya@ieee.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 15:46:24 -0000 On Wed, 17 Apr 2013, Behcet Sarikaya wrote: > Does it make sense to complicate the network with all these things if you > have a dual stack network? > > Is it to discourage people from using IPv4? Or be ready for IPv6 only > network? > > I don't understand. Some devices are not capable of dual stack, they are either single stack IPv4 or single stack IPv6. This is mobile. It's understandable that you feel things seem weird, because a lot of things in 3GPP land do not make sense unless you've worked with it a while and accept the quirks. -- Mikael Abrahamsson email: swmike@swm.pp.se From sander@steffann.nl Wed Apr 17 09:43:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6521F874E for ; Wed, 17 Apr 2013 09:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFrGQvrNulEp for ; Wed, 17 Apr 2013 09:43:05 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 12DC721F8738 for ; Wed, 17 Apr 2013 09:43:04 -0700 (PDT) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id A51DB204B; Wed, 17 Apr 2013 18:43:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Sander Steffann In-Reply-To: Date: Wed, 17 Apr 2013 18:43:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1143104E-8294-4643-83A6-8B63B9BA095A@steffann.nl> References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1503) Cc: IPv6 Ops WG Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 16:43:06 -0000 > This is mobile. It's understandable that you feel things seem weird, = because a lot of things in 3GPP land do not make sense unless you've = worked with it a while and accept the quirks. There is a big difference between accepting the quirks and them making = sense ;-) Sander From rajiva@cisco.com Wed Apr 17 16:41:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AC021E80E5 for ; Wed, 17 Apr 2013 16:41:41 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfSLbbS-8+Fg for ; Wed, 17 Apr 2013 16:41:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E544721E80AD for ; Wed, 17 Apr 2013 16:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2675; q=dns/txt; s=iport; t=1366242101; x=1367451701; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=+d8O5Ca0WISSnuwLNZNd6Rb8FrKK5wpKPSNRYffTvFE=; b=XzrKS3oGelWnVZzEQR937ssgaSI4nqzDkTM1mUMuAtHtVadg0IR3eCfY SAxn6UdEVJsgpdIDF9qwGIlJ7D7LThWqgvLCzkaMIKM9Rw4xK0HQ4ds5H 0/tYEBBVqW7PXY8eu9FU7iH3ZfxNx+DQDM9LD6JsQg+ZG6QAGdL1F8umu U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAHoyb1GtJXG+/2dsb2JhbABQgwY2wFOBBBZ0gh8BAQEEAQEBNzQXBgEIDgMDAQILFDcLHQgCBAESCIgMDL1KBI1YgREmEgaCX2EDqBqDC4FzNQ X-IronPort-AV: E=Sophos;i="4.87,496,1363132800"; d="scan'208";a="200015573" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 17 Apr 2013 23:41:40 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3HNfeHl008132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 23:41:40 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.247]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 18:41:40 -0500 From: "Rajiv Asati (rajiva)" To: Mikael Abrahamsson , "v6ops@ietf.org" Thread-Topic: [v6ops] combination of NAT64/DNS64 and NAT44 Thread-Index: AQHOO1Ww9p786KWCXUO2sRDH4qUGvJjbFCqA Date: Wed, 17 Apr 2013 23:41:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.113.148] Content-Type: text/plain; charset="us-ascii" Content-ID: <1B9DEB0F352C314199B3637525182F71@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 23:41:41 -0000 Hi Mikael, 1. Nothing major, however, minor side-effect is that the UE traffic could go over IPv4 when it should be going over IPv6 or vice versa, depending on which DNS response gets received sooner in the context of dual-stack devices (ignoring happy eyeball). 2. Your proposal has a nice property of seeing more IPv6 traffic inside the network (barring #1, or put it other way, if AAAA are always sent before A), and seeing IPv4 traffic for IPv4-only UEs (e.g. Motorola 3G smartphones) or IPv4-only apps (e.g. Skype 3. An automated way of figuring out which APN (for v4 only, v6 only, and DS!) to be used by which UE?? Cheers, Rajiv -----Original Message----- From: Mikael Abrahamsson Organization: People's Front Against WWW Date: Wednesday, April 17, 2013 6:23 AM To: "v6ops@ietf.org" Subject: [v6ops] combination of NAT64/DNS64 and NAT44 > >Hello. > >I would like to solicit some feedback on a deployment scenario. > >A device has dual stack access on its WAN access, with IPv4 RFC1918 >addresses or 100.64.0.0/10 address space on WAN side, and a CGN NAT44 >gateway for sharing these addresses towards the Internet, and GUA IPv6 >addresses. There is also a NAT64 gateway in the network, and a DNS64 >resolver reachable over IPv6. There is a regular resolver reachable over >IPv4. A dual stack client will get both types of resolvers. > >Now, aim is to support all kinds of devices, IPv4 only, IPv6 only, and >dual stack. The single stack cases are pretty obvious (IPv4 single stack >will use NAT44, IPv6 single stack will use NAT64/DNS64 and require >464XLAT=20 >for "proper" function), but my question relates to the dual stack case. >With a DNS64 based resolver, only IPv4 literals will go over the NAT44, >if=20 >the device uses the IPv6 based resolver. If it uses the IPv4 based >resolver, it will use the NAT44 device for IPv4 only sites. > >So my questions are: > >1. Is there a case where the above setup will cause problems? > >2. Does it make sense to turn on DNS64 even on the IPv4 based resolver? >This would cause AAAA lookups over IPv4 to steer traffic towards the >NAT64=20 >gateway, in case a client chooses to use the IPv4 based resolver for >lookups even if it's dual stacked. As far as I understand, a DNS64 based >resolver will forward A quaries unmodified so this shouldn't cause any >problems for single stacked IPv4 clients? > >3. Did I miss anything? > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From jouni.nospam@gmail.com Thu Apr 18 01:08:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E12621F8A48 for ; Thu, 18 Apr 2013 01:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coRn4tO7u+IU for ; Thu, 18 Apr 2013 01:08:53 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA5721F8C08 for ; Thu, 18 Apr 2013 01:08:53 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id s10so2434478lbi.19 for ; Thu, 18 Apr 2013 01:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=8Kof/VFKsppX8ueMQ6NVBIMXBWMpfTSOQo57PKNEm9M=; b=fRbiIOsf0q99WDY8JtKGs8sGiB9BrE5BjO1zQBGjAclck5iwnwwOJBlFBHnHjeXVQB k0LXm7ghswnl5BNDyqavzFcynh1ML1FxJcYI/GQ5Bm6DK/qpbM/9/K2eo/tBCK31VqXe b5HnGZoepENQAroeXGMSS80gYLJ1nGPyUjOmDax5sO5O/UnCOHDSkYxQTzAjZmVwW7ir hu+J5ONGfaiSY1oSwGAO/A+HYL7wis5FCmakBzdCjsqFesA7+ubZ+SKwym92j32yPwPQ 0r7w34OumoPTSJQMjtIWOnMVoqoHqyfVpaYBjXDb/5TwtdrUPboQxj3zjW6RifuL1DLC tE/A== X-Received: by 10.152.115.140 with SMTP id jo12mr5217542lab.53.1366272532326; Thu, 18 Apr 2013 01:08:52 -0700 (PDT) Received: from [192.168.250.209] ([194.100.71.98]) by mx.google.com with ESMTPS id y9sm3904699lae.10.2013.04.18.01.08.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 01:08:51 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <516EB7E9.6050805@viagenie.ca> Date: Thu, 18 Apr 2013 11:08:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2662C813-B6CF-48FE-A83A-ABE948B505F9@gmail.com> References: <516EB4EC.7010102@viagenie.ca> <516EB7E9.6050805@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1503) Cc: v6ops@ietf.org Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 08:08:54 -0000 On Apr 17, 2013, at 5:55 PM, Simon Perreault = wrote: > Le 2013-04-17 16:48, Mikael Abrahamsson a =E9crit : >>> Other than that, my main feedback would be: you want to provide = NATed >>> IPv4 alongside NAT64, doesn't that defeat the purpose of NAT64, i.e. >>> operating an IPv6-only network? >>=20 >> I want all kinds of terminals to be supported using single APN. I = don't >> want to care if the device connects using DS or single stack IPv4 or = IPv6. >=20 > IMHO, it would be better engineering-wise to provision different sets = of parameters for DS, SSv4, and SSv6. >=20 > DS: IPv6 + NAT44 > SSv4: NAT44 > SSv6: IPv6 + NAT64 >=20 > And you're lucky, you can even determine the kind of client based on = the PDP type. Others aren't so lucky... ;) >=20 > Can you do that using a single APN? In theory yes if AAA backend is used to provide per subscriber configuration to the GGSN/PGW.. However, the reality in actual products can be on a different orbit than specifications. Also it depends on the GGSN/PGW implementation how it handles the session profile for APNs and such.. - JOuni >=20 > Simon > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From phdgang@gmail.com Thu Apr 18 01:12:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB9B21F8E5C for ; Thu, 18 Apr 2013 01:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeO8PZ2CVH2c for ; Thu, 18 Apr 2013 01:12:15 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7E34A21F8A48 for ; Thu, 18 Apr 2013 01:12:15 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id cz11so1489422qeb.1 for ; Thu, 18 Apr 2013 01:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UBK58CPD7t3h5H/3QgidoOrWWf2uYjunvIS23IaMzKs=; b=uJTFSSnSEUfb7YMHV/AhZhshEhIyYEm06QBiSiRdBmBraoeCfcNjmKPfQVlLdLB7Ek iUcf2X4fPlGghmW18CGFAAqbQ8ig+eIt4qC6TMcei/S3HmEnJHftmkJxESfxrCG3VDji 5xO4oEeaqEmc5OXclCRJm56Cboe2cgXFmeC6RbDu+LoxcMWDREiHkJHxlZCKtCJyuJv4 WR0sDoSKd5T4pPV8FRuPNQBRgG2Z+6CJlwZOAHZf9uKj6TeH0gLiWHM6K5DrDKhzdPLt WZM3BxuVYsqB7rDZD/F6n3Ikm21KPPz7Z09zt5tzZ2mYmUWMf2qhNMgmubVr3E8cORh6 yhFA== MIME-Version: 1.0 X-Received: by 10.49.39.137 with SMTP id p9mr10452676qek.47.1366272734981; Thu, 18 Apr 2013 01:12:14 -0700 (PDT) Received: by 10.49.5.129 with HTTP; Thu, 18 Apr 2013 01:12:14 -0700 (PDT) In-Reply-To: References: <516EB4EC.7010102@viagenie.ca> Date: Thu, 18 Apr 2013 16:12:14 +0800 Message-ID: From: GangChen To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 08:12:19 -0000 2013/4/17, Mikael Abrahamsson : > On Wed, 17 Apr 2013, Simon Perreault wrote: > >> It might not be immediately useful to you, but you should know about this >> >> draft: >> https://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic > > Yep. Also RFC6877, but my guess would be that the 464XLAT would be > disabled when WAN port is dual stack? > >> Other than that, my main feedback would be: you want to provide NATed >> IPv4 alongside NAT64, doesn't that defeat the purpose of NAT64, i.e. >> operating an IPv6-only network? > > I want all kinds of terminals to be supported using single APN. I don't > want to care if the device connects using DS or single stack IPv4 or IPv6. Are you seeing IPv6-only PDN context? It's rather interested to hear more about it. BRs Gang > I don't control the end devices. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From swmike@swm.pp.se Thu Apr 18 01:13:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E5821F8606 for ; Thu, 18 Apr 2013 01:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3dq8mshQz-K for ; Thu, 18 Apr 2013 01:13:16 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1874821F845E for ; Thu, 18 Apr 2013 01:13:15 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 19E059C; Thu, 18 Apr 2013 10:13:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 12FB89A; Thu, 18 Apr 2013 10:13:14 +0200 (CEST) Date: Thu, 18 Apr 2013 10:13:14 +0200 (CEST) From: Mikael Abrahamsson To: Simon Perreault In-Reply-To: <516EB7E9.6050805@viagenie.ca> Message-ID: References: <516EB4EC.7010102@viagenie.ca> <516EB7E9.6050805@viagenie.ca> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 08:13:17 -0000 On Wed, 17 Apr 2013, Simon Perreault wrote: > IMHO, it would be better engineering-wise to provision different sets of > parameters for DS, SSv4, and SSv6. Yes, but this is hard to do in real life. > DS: IPv6 + NAT44 > SSv4: NAT44 > SSv6: IPv6 + NAT64 > > And you're lucky, you can even determine the kind of client based on the PDP > type. Others aren't so lucky... ;) > > Can you do that using a single APN? It might be possible, but I don't think it's feasable. I'd probably go for multiple APNs then, and provision different APNs depending on equipment type. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Apr 18 01:17:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7107621F845E for ; Thu, 18 Apr 2013 01:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzNPsHV6+0Qq for ; Thu, 18 Apr 2013 01:17:06 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id A82D021F8A48 for ; Thu, 18 Apr 2013 01:17:06 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 00C899C; Thu, 18 Apr 2013 10:17:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EBBD59A for ; Thu, 18 Apr 2013 10:17:05 +0200 (CEST) Date: Thu, 18 Apr 2013 10:17:05 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org In-Reply-To: Message-ID: References: <516EB4EC.7010102@viagenie.ca> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 08:17:07 -0000 On Thu, 18 Apr 2013, GangChen wrote: > Are you seeing IPv6-only PDN context? It's rather interested to hear > more about it. Well, my Samsung Galaxy Nexus supports IPv4 or IPv6 PDP context, not IPv4v6 or IPv4+IPv6. My hope to make this phone work is that Android 4.3 will include CLAT functionality in it, then IPv6 only PDP context + DNS64/NAT64 will hopefully work well enough. I have done testing with IPv6 only for several years and rejected it due to NAT64+DNS64 not working well enough without 464XLAT. Two PDP contexts (IPv4+IPv6) works well, but I don't want to deploy in volume it due to increased signalling load. So what are your interest in IPv6 only PDN context? -- Mikael Abrahamsson email: swmike@swm.pp.se From simon.perreault@viagenie.ca Thu Apr 18 01:21:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E9421F8F0D for ; Thu, 18 Apr 2013 01:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqMZI4dLBYap for ; Thu, 18 Apr 2013 01:21:28 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 67C4021F8F1C for ; Thu, 18 Apr 2013 01:21:24 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:a0bf:2ff:321b:e17b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9B04C40437; Thu, 18 Apr 2013 04:20:46 -0400 (EDT) Message-ID: <516FACDE.5090205@viagenie.ca> Date: Thu, 18 Apr 2013 10:20:46 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jouni Korhonen References: <516EB4EC.7010102@viagenie.ca> <516EB7E9.6050805@viagenie.ca> <2662C813-B6CF-48FE-A83A-ABE948B505F9@gmail.com> In-Reply-To: <2662C813-B6CF-48FE-A83A-ABE948B505F9@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 08:21:29 -0000 Le 2013-04-18 10:08, Jouni Korhonen a écrit : >> DS: IPv6 + NAT44 >> SSv4: NAT44 >> SSv6: IPv6 + NAT64 >> >> And you're lucky, you can even determine the kind of client based on the PDP type. Others aren't so lucky... ;) >> >> Can you do that using a single APN? > > In theory yes if AAA backend is used to provide per subscriber > configuration to the GGSN/PGW.. However, the reality in actual > products can be on a different orbit than specifications. Also > it depends on the GGSN/PGW implementation how it handles the > session profile for APNs and such.. Understood. That's what I expected too. *sigh* That's why we can't have nice things. Simon From phdgang@gmail.com Thu Apr 18 01:37:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D20E21F8F0E for ; Thu, 18 Apr 2013 01:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT+3xkH46u4V for ; Thu, 18 Apr 2013 01:37:25 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BD9C321F8F0C for ; Thu, 18 Apr 2013 01:37:25 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id b12so1177128qca.32 for ; Thu, 18 Apr 2013 01:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EsjnXL2bKo8YiOelgu1UJUV6k2Jc9wkrshFY5SS0gDo=; b=yYR6W96Mdh/VpjBy3GnDjD6XixwokIIlj4+xc1CQhbwHIB2rcDRKYcp8uh7P6bMPZ4 50TPDpaxXxPRmqYv0aTBnNILtwaBem/qKDWfF3SqEyW0s7x9HvSHHexSPrOzhkrvJMol +8l9h/4WAOVJKlUKP8Td0jzHkG3QRVQqpDdNZwHt5LpS+9YO9qdqHNqHoqknrcZxJITG VH/ZIe+LdiXpDqOYLan4X3nKgIixOVjm6c5Y1v0HLZTPU3GnLd3hzcOfL6nWAX2HT3qd rb4vXC06srcSmLu8lSKP8vu8IsYie+RLmycv+AbQZPA85qI2V/K1Xi1FvSi0Ybo3TnQl JpUg== MIME-Version: 1.0 X-Received: by 10.224.36.6 with SMTP id r6mr2345685qad.84.1366274245129; Thu, 18 Apr 2013 01:37:25 -0700 (PDT) Received: by 10.49.5.129 with HTTP; Thu, 18 Apr 2013 01:37:25 -0700 (PDT) In-Reply-To: References: <516EB4EC.7010102@viagenie.ca> Date: Thu, 18 Apr 2013 16:37:25 +0800 Message-ID: From: GangChen To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 08:37:26 -0000 2013/4/18, Mikael Abrahamsson : > On Thu, 18 Apr 2013, GangChen wrote: > >> Are you seeing IPv6-only PDN context? It's rather interested to hear >> more about it. > > Well, my Samsung Galaxy Nexus supports IPv4 or IPv6 PDP context, not > IPv4v6 or IPv4+IPv6. Is this a situation for 3G mode. I heard most HSDPA terminals are R6 and HSUPA are R7 Those terminals can not support IPv4v6 PDP context. > My hope to make this phone work is that Android 4.3 > will include CLAT functionality in it, then IPv6 only PDP context + > DNS64/NAT64 will hopefully work well enough. > > I have done testing with IPv6 only for several years and rejected it due > to NAT64+DNS64 not working well enough without 464XLAT. Two PDP contexts > (IPv4+IPv6) works well, but I don't want to deploy in volume it due to > increased signalling load. Good. I guess that is a right way to go. > So what are your interest in IPv6 only PDN context? My thought was about terminals which are post-R8, especially LTE modes. Basically it supports dual-stack PDN activation. IPv6-only PDN context is desirable, but it seems vulnerable when the terminals are roaming to a IPv6-disable network. Dual-stack PDN could fall back to IPv4 in that case. I'm not sure what is the behavior for IPv6-only PDN context. Fallback to IPv4 seems straightforward. However, 3GPP doesn't give the words to describe. BRs Gang > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From swmike@swm.pp.se Thu Apr 18 01:50:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD4C21F8ED5 for ; Thu, 18 Apr 2013 01:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hit-kUrcse-s for ; Thu, 18 Apr 2013 01:50:53 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id BDAF821F8AB0 for ; Thu, 18 Apr 2013 01:50:51 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BB9B99C; Thu, 18 Apr 2013 10:50:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B11B09A; Thu, 18 Apr 2013 10:50:49 +0200 (CEST) Date: Thu, 18 Apr 2013 10:50:49 +0200 (CEST) From: Mikael Abrahamsson To: GangChen In-Reply-To: Message-ID: References: <516EB4EC.7010102@viagenie.ca> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 08:50:54 -0000 On Thu, 18 Apr 2013, GangChen wrote: >> Well, my Samsung Galaxy Nexus supports IPv4 or IPv6 PDP context, not >> IPv4v6 or IPv4+IPv6. > > Is this a situation for 3G mode. I heard most HSDPA terminals are R6 and > HSUPA are R7 Those terminals can not support IPv4v6 PDP context. Might be so. But they can support IPv4+IPv6, but the Galaxy Nexus doesn't. Even my old Nokia N900 could do IPv4+IPv6 by editing the startup scripts. > My thought was about terminals which are post-R8, especially LTE modes. > Basically it supports dual-stack PDN activation. IPv6-only PDN context > is desirable, but it seems vulnerable when the terminals are roaming to > a IPv6-disable network. Dual-stack PDN could fall back to IPv4 in that > case. I'm not sure what is the behavior for IPv6-only PDN context. > Fallback to IPv4 seems straightforward. However, 3GPP doesn't give the > words to describe. IPv4v6 is fairly new, so a lot of network components don't support it, or it's not well tested. For LTE it generally works out of the box if it's enabled in config everywhere. Most newer LTE terminals support it as well, if the vendor hasn't disabled it in the GUI. I think Android GUI option to have a separate "roaming APN protocol" option and "APN protocol" option, so that it can be IPv4 when roaming, and whatever (IPv4v6 or IPv6) when in the home network, is sensible. Generally the 3GPP standard makes a lot of sense, unfortunately there are network components that go BOOM when they see IPv6 or IPv4v6 requests, as some of us have noticed. This is especially a roaming problem, since it's doable to qualify ones own network, but qualifying everybody elses is another matter. -- Mikael Abrahamsson email: swmike@swm.pp.se From tsavo.stds@gmail.com Thu Apr 18 04:55:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C285721F8E67 for ; Thu, 18 Apr 2013 04:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqnPlxL8nOp1 for ; Thu, 18 Apr 2013 04:55:08 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id D824421F8E4E for ; Thu, 18 Apr 2013 04:55:07 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id c10so1723265wiw.2 for ; Thu, 18 Apr 2013 04:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=N6KClMNffIAeMO3GD9zGuhY8/RKunrZeUGhQfWLDBW8=; b=LyocSsPZp+Cd3MElyPaHCfofptGR1IP84EcMFJxPOS9x5d22iyFlQvjeGcfH6tbUod CpzwV6J0Lp/gdhqHMd1Sg/1nVvwctqgQUX/1a9PBB/VuiRj3VyYMt+dWOaSztKoVREav yBBAcrpBOYzDW3FL5g4T9PIOtK6iGfhPNglBWugV6JjooroqbxQaVJpcRbXZTakqI3H9 oulQ23m5O1XdoX/X3W4o4b58GVlBQxxQQW9zPJaLXlljeKgB2a5GWIKP6stHsOoPAYtK HboKDxVh/R5bjurUiPH6eA5RvHJ70KAMH7jnRkW+ibMoH+JToHojmzYmlgO2NXHtmS+E h0uw== MIME-Version: 1.0 X-Received: by 10.194.123.168 with SMTP id mb8mr18099263wjb.24.1366286106914; Thu, 18 Apr 2013 04:55:06 -0700 (PDT) Received: by 10.194.152.71 with HTTP; Thu, 18 Apr 2013 04:55:06 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EBBE68FFC@PUEXCB1B.nanterre.francetelecom.fr> References: <20130327093238.29058.4046.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EBBE68FFC@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 18 Apr 2013 14:55:06 +0300 Message-ID: From: Teemu Savolainen To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=089e011831121075f704daa146dc Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 11:55:09 -0000 --089e011831121075f704daa146dc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Med, all, I gave this document a full read with following comments: 1) I think "mobile devices" is perhaps too wide a name - should this explicitly say "3gpp mobile devices" or "cellular hosts". 2) In my opinion all references to 3316 should be changed to draft-ietf-v6ops-rfc3316bis, and there is no need to compare RFC3316 with 3316bis draft in here (in section 1), as the 3316bis will obsolete the 3316= . 3) The abstract talks about "device with LAN" capabilities. That is ambiguous, as I think you mean LAN on "downlink" of the device? I mean a device with WiFi connection has "LAN capability" even if it does not have tethering capabilities:) "Both hosts and devices with capability to share their WAN connectivity to LAN" or something? 3) Why some of the requirements of RFC6434 are duplicated herein with same keywords, e.g. REQ#1 has MUST for same thing RFC6434 has MUST. I would suppose a profile document could say that mobile device MUST follow RFC6434, except when ? 4) REQ#2 title does not include IPv4, but IPv4 PDP is mentioned in text:"in addition to the IPv4 PDP context." Does this mean IPv4 PDP context is also required, or is IPv4 PDP optional? Needs clarification. 5) Is it required to be able to support different PDP types in parallel, e.g. IPv4 in parallel with IPv4v6? That probably is (e.g. IPv4 for MMS, IPv4v6 for Internet), but do you wish to write it down? 6) REQ#3 says device MUST request IPv4v6 if the cellular host is dual-stack. Well, this is how 3GPP writes it as well... but in reality all this depends on provisioning. So you should say that this is the way, unless provisioned to do otherwise.. 7) REQ#3 bullet 1, I don't follow. It says that if network does not have IPv4v6, but "IPv4 and IPv6", then the network will configure IPv4 address and IPv6 prefix. This is does not tell really much, IPv4 address and IPv6 prefix are provided if IPv4v6 is supported, or if IPv4 and IPv6 are allowed in parallel. Maybe this gets fixed if you change "and/or" to just "or". Because if network gives only IPv4 or IPv6, then the device can ask for parallel bearer. 8) REQ#3 bullet 1: I would change the MAY open initiate another PDP to SHOULD or MUST. This is because device is dual-stack capable, has requested IPv4v6, but only gotten IPv4 or IPv6. If the network does not indicate "single bearer only", then IMHO the device MUST ask for parallel PDP - which the network can reject. I.e. dual-stack host should ask for IPv4v6, then IPv4 and IPv6 in parallel. Exceptions are provisioning or error codes available at and after release-8. 9) REQ#4: What about RFC6106? I would think that could be MAY/SHOULD in addition to MUST for PCO option support. 10) REQ#6: should you clarify that MTU option really needs to be received and acted upon? 11) REQ#9 says in title "must" but in text "SHOULD". Which way do you intend? I could go for MUST in order to allow more flexibility in the future, but SHOULD is ok as well 12) REQ#10 says in title "must", but why? What if device just does not need anything via stateless DHCPv6? SHOULD would be better? 13) The DNS discovery is split into REQ#4, REQ#9, and REQ#10. The REQ#10 is the only that says preference order (with PCP, should probably be PCO instead). Could these REQs be combined? Should the preference order be a separate requirement ? 14) REQ#11 do you have requirement 15) REQ#13 could have pointer/dependency to REQ#11? I take DNSSEC support goes off-scope - but nevertheless REQ#13 is needed only if device supports DNSSEC, or 464XLAT? 16) REQ#15 refers to MIF - I would probably simply drop the MIF reference out, as if MIF is included also other problems start creeping in (specific routes, DNS selection, provisioning domains...) - i.e. better exclude MIF problematics from this document. You could explicitly state whether you prefer DNS communications to use IPv4 or IPv6 in dual-stack scenarios, as that seems to be something currently more or less random. 17) Section 2.1 I would like clarification whether this applies to "downlink" WiFi, "uplink" WiFi, or both. It sounds like about uplink, but please spell it out. 18) WiFi is a trademark owned by WiFi Alliance. Based on prior feedback to me, I would rather talk about IEEE 802.11, or WLAN here as well. 19) REQ#19 I would remove the background text about "some recent tests revealed" on some OS - it just does not suit well for profile document living for a looong time. Alternatively you could have Appendix that includes some of the real-world experiences of particular implementations? 20) REQ#22 why this is advanced requirement? I would call it basic.. and I would like to emphasize capability to receive MTU option via RA. 21) REQ#23 - I am not convinced full RFC4941 is always required. Enough private addresses could be obtained by simpler ways as well, I believe. Hence I would rephrase that hosts MUST have RFC4941 or other means for providing privacy addressing. I.e. the requirement should be about privacy addresses, not RFC4941. 22) REQ#24 is too ambiguous. Please state which ROHC profiles. AFAIK VoLTE requires RTP/UDP/IP, but nobody is requiring TCP profile (because for (Voice)/RTP/UDP/IP the savings in compressed headers are significant, but for TCP bulk download the savings are insignificant and when compared to overall costs (cost of compressing/decompressing) probably close to negative). 23) Section 4 title - please clarify this is downlink LAN 24) REQ#27 makes 3GPP-wise sense only on Release-10 based networks. Do you intent this requirement to cover all IPv6 hosts from 3GPP Release-99 onwards (cherry picking)? Please clarify in either case. 25) REQ#33 this is something handset vendors have only so much control over.. but maybe this document can also be given for application writers?-) Best regards, Teemu 2013/3/27 > Dear all, > > The changes in the new version are as follows: > > (1) Tweak the text in the Abstract and Introduction to answer to the > comment raised by F. Baker here: > http://www.ietf.org/mail-archive/web/v6ops/current/msg15672.html > (2) Soften the tone for REQ#29 as discussed with Mickael here: > http://www.ietf.org/mail-archive/web/v6ops/current/msg15742.html > (3) Add a disclaimer some features require activating some functions at > the network side as suggested by Jouni > (4) Add an explicit reference to RFC6434 + whenever needed, indicate > whether the new language form is stronger + Justification. > > The new version integrates all the comments received so far. > > Cheers, > Med > > >-----Message d'origine----- > >De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De > >la part de internet-drafts@ietf.org > >Envoy=E9 : mercredi 27 mars 2013 10:33 > >=C0 : i-d-announce@ietf.org > >Cc : v6ops@ietf.org > >Objet : [v6ops] I-D Action: > >draft-ietf-v6ops-mobile-device-profile-01.txt > > > > > >A New Internet-Draft is available from the on-line > >Internet-Drafts directories. > > This draft is a work item of the IPv6 Operations Working > >Group of the IETF. > > > > Title : Internet Protocol Version 6 (IPv6) > >Profile for Mobile Devices > > Author(s) : David Binet > > Mohamed Boucadair > > Ales Vizdal > > Cameron Byrne > > Gang Chen > > Filename : draft-ietf-v6ops-mobile-device-profile-01.txt > > Pages : 16 > > Date : 2013-03-27 > > > >Abstract: > > This document specifies an IPv6 profile for mobile devices. > > It lists > > the set of features a mobile device is to be compliant with to > > connect to an IPv6-only or dual-stack mobile network. > > > > This document defines a different profile than the one for general > > connection to IPv6 mobile networks defined in [RFC3316]. In > > particular, this document identifies also features to ensure IPv4 > > service continuity over an IPv6-only transport. > > > > Both Hosts and devices with LAN capabilities are in scope. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-01 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device > >-profile-01 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e011831121075f704daa146dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Med, all,

I gave this document a full r= ead with following comments:
1) I think "mobile devices"= ; is perhaps too wide a name - should this explicitly say "3gpp mobile= devices" or "cellular hosts".=A0
2) In my opinion all references to 3316 should be changed to draft-iet= f-v6ops-rfc3316bis, and there is no need to compare RFC3316 with 3316bis dr= aft in here (in section 1), as the 3316bis will obsolete the 3316.
3) The abstract talks about "device with LAN" capabilities. = That is ambiguous, as I think you mean LAN on "downlink" of the d= evice? I mean a device with WiFi connection has "LAN capability" = even if it does not have tethering capabilities:) "Both hosts and devi= ces with capability to share their WAN connectivity to LAN" or somethi= ng?
3) Why some of the requirements of RFC6434 are duplicated herein with = same keywords, e.g. REQ#1 has MUST for same thing RFC6434 has MUST. I would= suppose a profile document could say that mobile device MUST follow RFC643= 4, except when <exceptions> ?
4) REQ#2 title does not include IPv4, but IPv4 PDP is mentioned in tex= t:"in addition to the IPv4 PDP context." Does this mean IPv4 PDP = context is also required, or is IPv4 PDP optional? Needs clarification.
5) Is it required to be able to support different PDP types in paralle= l, e.g. IPv4 in parallel with IPv4v6? That probably is (e.g. IPv4 for MMS, = IPv4v6 for Internet), but do you wish to write it down?
6) REQ#3 says device MUST request IPv4v6 if the cellular host is dual-stack= . Well, this is how 3GPP writes it as well... but in reality all this depen= ds on provisioning. So you should say that this is the way, unless provisio= ned to do otherwise..
7) REQ#3 bullet 1, I don't follow. It says that if network does no= t have IPv4v6, but "IPv4 and IPv6", then the network will configu= re IPv4 address and IPv6 prefix. This is does not tell really much, IPv4 ad= dress and IPv6 prefix are provided if IPv4v6 is supported, or if IPv4 and I= Pv6 are allowed in parallel. Maybe this gets fixed if you change "and/= or" to just "or". Because if network gives only IPv4 or IPv6= , then the device can ask for parallel bearer.
8) REQ#3 bullet 1: I would change the MAY open initiate another PDP to= SHOULD or MUST. This is because device is dual-stack capable, has requeste= d IPv4v6, but only gotten IPv4 or IPv6. If the network does not indicate &q= uot;single bearer only", then IMHO the device MUST ask for parallel PD= P - which the network can reject. I.e. dual-stack host should ask for IPv4v= 6, then IPv4 and IPv6 in parallel. Exceptions are provisioning or error cod= es available at and after release-8.
9) REQ#4: What about RFC6106? I would think that could be MAY/SHOULD i= n addition to MUST for PCO option support.
10) REQ#6: should you = clarify that MTU option really needs to be received and acted upon?
11) REQ#9 says in title "must" but in text "SHOULD"= ;. Which way do you intend? I could go for MUST in order to allow more flex= ibility in the future, but SHOULD is ok as well
12) REQ#10 says i= n title "must", but why? What if device just does not need anythi= ng via stateless DHCPv6? SHOULD would be better?
13) The DNS discovery is split into REQ#4, REQ#9, and REQ#10. The REQ#= 10 is the only that says preference order (with PCP, should probably be PCO= instead). Could these REQs be combined? Should the preference order be a s= eparate requirement ?
14) REQ#11 do you have requirement
15) REQ#13 could have pointer/dependency to REQ#11? I take= DNSSEC support goes off-scope - but nevertheless REQ#13 is needed only if = device supports DNSSEC, or 464XLAT?
16) REQ#15 refers to MI= F - I would probably simply drop the MIF reference out, as if MIF is includ= ed also other problems start creeping in (specific routes, DNS selection, p= rovisioning domains...) - i.e. better exclude MIF problematics from this do= cument. You could explicitly state whether you prefer DNS communications to= use IPv4 or IPv6 in dual-stack scenarios, as that seems to be something cu= rrently more or less random.
17) Section 2.1 I would like clarification whether this applies = to "downlink" WiFi, "uplink" WiFi, or both. It sounds l= ike about uplink, but please spell it out.
18) WiFi is a tr= ademark owned by WiFi Alliance. Based on prior feedback to me, I would rath= er talk about IEEE 802.11, or WLAN here as well.
19) REQ#19 I would remove the background text about "some r= ecent tests revealed" on some OS - it just does not suit well for prof= ile document living for a looong time. Alternatively you could have Appendi= x that includes some of the real-world experiences of particular implementa= tions?
20) REQ#22 why this is advanced requirement? I would call it bas= ic.. and I would like to emphasize capability to receive MTU option via RA.=
21) REQ#23 - I am not convinced full RFC4941 is always req= uired. Enough private =A0addresses could be obtained by simpler ways as wel= l, I believe. Hence I would rephrase that hosts MUST have RFC4941 or other = means for providing privacy addressing. I.e. the requirement should be abou= t privacy addresses, not RFC4941.
22) REQ#24 is too ambiguous. Please state which ROHC profiles. A= FAIK VoLTE requires RTP/UDP/IP, but nobody is requiring TCP profile (becaus= e for (Voice)/RTP/UDP/IP the savings in compressed headers are significant,= but for TCP bulk download the savings are insignificant and when compared = to overall costs (cost of compressing/decompressing) probably close to nega= tive).=A0
23) Section 4 title - please clarify this is downlink LAN=A0
24) REQ#27 makes 3GPP-wise sense only on Release-10 based netw= orks. Do you intent this requirement to cover all IPv6 hosts from 3GPP Rele= ase-99 onwards (cherry picking)? Please clarify in either case.
25) REQ#33 this is something handset vendors have only so much c= ontrol over.. but maybe this document can also be given for application wri= ters?-)


Best rega= rds,

Teemu




2013/3/27 <mohamed.boucadair@orange.com>
Dear all,

The changes in the new version are as follows:

(1) Tweak the text in the Abstract and Introduction to answer to the commen= t raised by F. Baker here: http://www.ietf.org/mail-arc= hive/web/v6ops/current/msg15672.html
(2) Soften the tone for REQ#29 as discussed with Mickael here: http://www.ietf.org/mail-archive/web/v6ops/current/msg15742.html
(3) Add a disclaimer some features require activating some functions at the= network side as suggested by Jouni
(4) Add an explicit reference to RFC6434 + whenever needed, indicate whethe= r the new language form is stronger + Justification.

The new version integrates all the comments received so far.

Cheers,
Med

>-----Message d'origine-----
>De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org= ] De
>la part de internet-drafts@= ietf.org
>Envoy=E9 : mercredi 27 mars 2013 10:33
>=C0 : i-d-announce@ietf.org
>Cc : v6ops@ietf.org
>Objet : [v6ops] I-D Action:
>draft-ietf-v6ops-mobile-device-profile-01.txt
>
>
>A New Internet-Draft is available from the on-line
>Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations Working
>Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Internet Protocol Version 6 (I= Pv6)
>Profile for Mobile Devices
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : David Binet
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mohamed Boucadair > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ales Vizdal
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Cameron Byrne
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Gang Chen
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-mobile-device-p= rofile-01.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 16
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-03-27
>
>Abstract:
> =A0 This document specifies an IPv6 profile for mobile devices.
> It lists
> =A0 the set of features a mobile device is to be compliant with to
> =A0 connect to an IPv6-only or dual-stack mobile network.
>
> =A0 This document defines a different profile than the one for general=
> =A0 connection to IPv6 mobile networks defined in [RFC3316]. =A0In
> =A0 particular, this document identifies also features to ensure IPv4<= br> > =A0 service continuity over an IPv6-only transport.
>
> =A0 Both Hosts and devices with LAN capabilities are in scope.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-= v6ops-mobile-device-profile
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-v6ops-mob= ile-device-profile-01
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6op= s-mobile-device
>-profile-01
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp:/= /ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--089e011831121075f704daa146dc-- From mohamed.boucadair@orange.com Thu Apr 18 07:58:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9943B21F85CC for ; Thu, 18 Apr 2013 07:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.636 X-Spam-Level: X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2fGXnTsYvGw for ; Thu, 18 Apr 2013 07:58:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 640B321F859A for ; Thu, 18 Apr 2013 07:58:21 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 0C0E9324896; Thu, 18 Apr 2013 16:58:20 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E774C23804B; Thu, 18 Apr 2013 16:58:19 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 18 Apr 2013 16:58:19 +0200 From: To: Teemu Savolainen Date: Thu, 18 Apr 2013 16:58:18 +0200 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt Thread-Index: Ac48K5Ki8Aej/6TTT2WHK+wJVx44wAABZmJw Message-ID: <94C682931C08B048B7A8645303FDC9F36EC73F1B67@PUEXCB1B.nanterre.francetelecom.fr> References: <20130327093238.29058.4046.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EBBE68FFC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EC73F1B67PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.18.132118 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 14:58:29 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EC73F1B67PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Teemu, Many thanks for your detailed review. Please see inline. Cheers, Med De : Teemu Savolainen [mailto:tsavo.stds@gmail.com] Envoy=E9 : jeudi 18 avril 2013 13:55 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : v6ops@ietf.org Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.t= xt Med, all, I gave this document a full read with following comments: 1) I think "mobile devices" is perhaps too wide a name - should this explic= itly say "3gpp mobile devices" or "cellular hosts". [Med] 3GPP Mobile Devices would be OK. 2) In my opinion all references to 3316 should be changed to draft-ietf-v6o= ps-rfc3316bis, [Med] Will see how to update the text. and there is no need to compare RFC3316 with 3316bis draft in here (in sect= ion 1), as the 3316bis will obsolete the 3316. [Med] Are you referring to this text? [RFC3316] lists a set of features to be supported by cellular hosts to connect to 3GPP cellular networks. Since the publication of that document, new functions have been specified within the 3GPP and the IETF whilst others have been updated. Moreover, in the light of recent IPv6 production deployments, additional features to facilitate IPv6-only deployments while accessing IPv4-only service are to be considered. Are you suggesting this text is to be removed? 3) The abstract talks about "device with LAN" capabilities. That is ambiguo= us, as I think you mean LAN on "downlink" of the device? I mean a device wi= th WiFi connection has "LAN capability" even if it does not have tethering = capabilities:) "Both hosts and devices with capability to share their WAN c= onnectivity to LAN" or something? [Med] I got your point. Will tweak the text. 3) Why some of the requirements of RFC6434 are duplicated herein with same = keywords, e.g. REQ#1 has MUST for same thing RFC6434 has MUST. I would supp= ose a profile document could say that mobile device MUST follow RFC6434, ex= cept when ? [Med] Isn't this covered by this text: Pointers to some requirements listed in [RFC6434] are included in this profile. The justification for using a stronger language compared to what is specified in [RFC6434] is provided for some requirements. If you think this is not clear, we can update the text to better clarify th= e logic. 4) REQ#2 title does not include IPv4, but IPv4 PDP is mentioned in text:"in= addition to the IPv4 PDP context." Does this mean IPv4 PDP context is also= required, or is IPv4 PDP optional? Needs clarification. [Med] The title focuses only on the IPv6-related PDP contexts. I don't thin= k there is a value to use the normative language for IPv4 PDP. 5) Is it required to be able to support different PDP types in parallel, e.= g. IPv4 in parallel with IPv4v6? That probably is (e.g. IPv4 for MMS, IPv4v= 6 for Internet), but do you wish to write it down? [Med] IMHO, this is not specific to IPv6. I don't think there is a value to= explicit this for IPv6-related PDP contexts. 6) REQ#3 says device MUST request IPv4v6 if the cellular host is dual-stack= . Well, this is how 3GPP writes it as well... but in reality all this depen= ds on provisioning. So you should say that this is the way, unless provisio= ned to do otherwise.. [Med] Would you be OK if the text is changed as follows: OLD: the cellular host MUST request ... NEW: the cellular host MUST request by default ... 7) REQ#3 bullet 1, I don't follow. It says that if network does not have IP= v4v6, but "IPv4 and IPv6", then the network will configure IPv4 address and= IPv6 prefix. This is does not tell really much, IPv4 address and IPv6 pref= ix are provided if IPv4v6 is supported, or if IPv4 and IPv6 are allowed in = parallel. Maybe this gets fixed if you change "and/or" to just "or". Becaus= e if network gives only IPv4 or IPv6, then the device can ask for parallel = bearer. [Med] Fixed. 8) REQ#3 bullet 1: I would change the MAY open initiate another PDP to SHOU= LD or MUST. This is because device is dual-stack capable, has requested IPv= 4v6, but only gotten IPv4 or IPv6. If the network does not indicate "single= bearer only", then IMHO the device MUST ask for parallel PDP - which the n= etwork can reject. I.e. dual-stack host should ask for IPv4v6, then IPv4 an= d IPv6 in parallel. Exceptions are provisioning or error codes available at= and after release-8. [Med] The text will be fixed. 9) REQ#4: What about RFC6106? I would think that could be MAY/SHOULD in add= ition to MUST for PCO option support. [Med] This is discussed in REQ#9. No? 10) REQ#6: should you clarify that MTU option really needs to be received a= nd acted upon? [Med] Can you explicit what change you want to see added to the text? 11) REQ#9 says in title "must" but in text "SHOULD". Which way do you inten= d? I could go for MUST in order to allow more flexibility in the future, bu= t SHOULD is ok as well [Med] "must comply" with Section 7.3 means it needs to follow what is descr= ibed in that section: i.e., SHOULD support 6106. This is indicated explicit= ly in the text. 12) REQ#10 says in title "must", but why? What if device just does not need= anything via stateless DHCPv6? SHOULD would be better? [Med] Idem as above. 13) The DNS discovery is split into REQ#4, REQ#9, and REQ#10. The REQ#10 is= the only that says preference order (with PCP, should probably be PCO inst= ead). Could these REQs be combined? Should the preference order be a separa= te requirement ? [Med] Fixed the typo with PCP. OK to have a separate requirement for the pr= eference order. 14) REQ#11 do you have requirement [Med] See the justification text and also the DNSSEC case. 15) REQ#13 could have pointer/dependency to REQ#11? I take DNSSEC support g= oes off-scope - but nevertheless REQ#13 is needed only if device supports D= NSSEC, or 464XLAT? [Med] Added a pointer to REQ#11. 16) REQ#15 refers to MIF - I would probably simply drop the MIF reference o= ut, as if MIF is included also other problems start creeping in (specific r= outes, DNS selection, provisioning domains...) - i.e. better exclude MIF pr= oblematics from this document. You could explicitly state whether you prefe= r DNS communications to use IPv4 or IPv6 in dual-stack scenarios, as that s= eems to be something currently more or less random. [Med] No problem to remove the MIF reference. For the DNS case, are you sug= gesting to add a sentence such as: "When both IPv4 and IPv6 DNS servers are configured, a dual-stack host MUST= contact first its IPv6 DNS server." 17) Section 2.1 I would like clarification whether this applies to "downlin= k" WiFi, "uplink" WiFi, or both. It sounds like about uplink, but please sp= ell it out. [Med] What difference do you make between those two? 18) WiFi is a trademark owned by WiFi Alliance. Based on prior feedback to = me, I would rather talk about IEEE 802.11, or WLAN here as well. [Med] Fixed. Thanks. 19) REQ#19 I would remove the background text about "some recent tests reve= aled" on some OS - it just does not suit well for profile document living f= or a looong time. Alternatively you could have Appendix that includes some = of the real-world experiences of particular implementations? [Med] We put that text there to record the encountered issue with some impl= ementations. If the requirement is supported, this wouldn't be an issue. I = will discuss with my co-author how to handle this comment. Thanks. 20) REQ#22 why this is advanced requirement? I would call it basic.. and I = would like to emphasize capability to receive MTU option via RA. [Med] Would moving this REQ to be called out just after REQ#6 be OK with yo= u? 21) REQ#23 - I am not convinced full RFC4941 is always required. Enough pri= vate addresses could be obtained by simpler ways as well, I believe. Hence= I would rephrase that hosts MUST have RFC4941 or other means for providing= privacy addressing. I.e. the requirement should be about privacy addresses= , not RFC4941. [Med] Makes sense. What about this change? OLD: The cellular host must comply with Section 5.9.3 of [RFC6434] for t= he support of the Privacy Extensions for Stateless Address Autoconfiguration in IPv6. The activation of privacy extension makes it more difficult to track a host over time when compared to using a permanent interface identifier. [RFC4941] does not require any DAD mechanism to be activated as the GGSN (or PDN-GW) MUST NOT configure any global address based on the prefix allocated to the cellular host. NEW: The cellular host MUST be able able to generate IPv6 addresses which preser= ve privacy. The activation of privacy extension (e.g., using [RFC4941]) makes it more difficult to track a host over time when compared to using a permanent interface identifier. Note, [RFC4941] does not require any DAD mechanism to be activated as the GGSN (or PDN-GW) MUST NOT configure any global address based on the prefix allocated to the cellular host. 22) REQ#24 is too ambiguous. Please state which ROHC profiles. AFAIK VoLTE = requires RTP/UDP/IP, but nobody is requiring TCP profile (because for (Voic= e)/RTP/UDP/IP the savings in compressed headers are significant, but for TC= P bulk download the savings are insignificant and when compared to overall = costs (cost of compressing/decompressing) probably close to negative). [Med] This is a very good point. I do personally agree with you. Let see wh= at there other think, if no objection is raised, we will adopt your suggest= ion. 23) Section 4 title - please clarify this is downlink LAN 24) REQ#27 makes 3GPP-wise sense only on Release-10 based networks. Do you = intent this requirement to cover all IPv6 hosts from 3GPP Release-99 onward= s (cherry picking)? Please clarify in either case. [Med] Just like REQ#29, the tone has been softened to not mention any 3GPP = release as discussed here: http://www.ietf.org/mail-archive/web/v6ops/curre= nt/msg15742.html. 25) REQ#33 this is something handset vendors have only so much control over= .. but maybe this document can also be given for application writers?-) [Med] I was aware of applications developed by the same mobile device vendo= r but are not IPv6-compatible. The requirement as currently worded is valid= for all applications. Best regards, Teemu 2013/3/27 > Dear all, The changes in the new version are as follows: (1) Tweak the text in the Abstract and Introduction to answer to the commen= t raised by F. Baker here: http://www.ietf.org/mail-archive/web/v6ops/curre= nt/msg15672.html (2) Soften the tone for REQ#29 as discussed with Mickael here: http://www.i= etf.org/mail-archive/web/v6ops/current/msg15742.html (3) Add a disclaimer some features require activating some functions at the= network side as suggested by Jouni (4) Add an explicit reference to RFC6434 + whenever needed, indicate whethe= r the new language form is stronger + Justification. The new version integrates all the comments received so far. Cheers, Med >-----Message d'origine----- >De : v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] De >la part de internet-drafts@ietf.org >Envoy=E9 : mercredi 27 mars 2013 10:33 >=C0 : i-d-announce@ietf.org >Cc : v6ops@ietf.org >Objet : [v6ops] I-D Action: >draft-ietf-v6ops-mobile-device-profile-01.txt > > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working >Group of the IETF. > > Title : Internet Protocol Version 6 (IPv6) >Profile for Mobile Devices > Author(s) : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : draft-ietf-v6ops-mobile-device-profile-01.txt > Pages : 16 > Date : 2013-03-27 > >Abstract: > This document specifies an IPv6 profile for mobile devices. > It lists > the set of features a mobile device is to be compliant with to > connect to an IPv6-only or dual-stack mobile network. > > This document defines a different profile than the one for general > connection to IPv6 mobile networks defined in [RFC3316]. In > particular, this document identifies also features to ensure IPv4 > service continuity over an IPv6-only transport. > > Both Hosts and devices with LAN capabilities are in scope. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device >-profile-01 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_94C682931C08B048B7A8645303FDC9F36EC73F1B67PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Teemu,=

 

Many thanks for your detailed review.

=

 

Cheers,

Med

 =

De : Teemu Savolain= en [mailto:tsavo.stds@gmail.com]
Envoy=E9 : jeudi 18 avril = 2013 13:55
=C0 : BOUCADAIR Mohamed OLNC/OLN
Cc :<= /b> v6ops@ietf.org
Objet : Re: [v6ops] I-D Action: draft-iet= f-v6ops-mobile-device-profile-01.txt

 

Med, all,

 

I gave this document a full read with following comments:

1) I think = "mobile devices" is perhaps too wide a name - should this explici= tly say "3gpp mobile devices" or "cellular hosts".

= [Med] 3GPP Mobile Devices would be OK.

 

2) In my opinion all references to= 3316 should be changed to draft-ietf-v6ops-rfc3316bis,

[Me= d] Will see how to update the text.

 

and there is no need to compare RFC3316 with 3316bis draft in here= (in section 1), as the 3316bis will obsolete the 3316.

[Med] Are you referring to this text?

 <= /p>

=A0=A0 [RFC3316] lists a set= of features to be supported by cellular hosts

=A0=A0 to connect to 3GPP cellular networks.=A0 Since the public= ation of that

=A0=A0 document, new f= unctions have been specified within the 3GPP and the

<= p class=3DMsoNormal>=A0=A0 IETF whilst others have been updated.=A0 Moreover, = in the light of

=A0=A0 recent IPv6 p= roduction deployments, additional features to facilitate<= /p>

=A0=A0 IPv6-only deployments while accessing IPv4-only= service are to be

=A0=A0 considered.

 

<= p class=3DMsoNormal>Are you suggesting this text is to be remove= d?

 <= /span>

3) The abstract talks about "= ;device with LAN" capabilities. That is ambiguous, as I think you mean= LAN on "downlink" of the device? I mean a device with WiFi conne= ction has "LAN capability" even if it does not have tethering cap= abilities:) "Both hosts and devices with capability to share their WAN= connectivity to LAN" or something?

[Med] I got your point. Will tweak the text.<= /p>

 

<= p class=3DMsoNormal>3) Why some of the requirements of RFC6434 are duplicat= ed herein with same keywords, e.g. REQ#1 has MUST for same thing RFC6434 ha= s MUST. I would suppose a profile document could say that mobile device MUS= T follow RFC6434, except when <exceptions> ?

[Med] Isn’t this covered by this text:

 

= 
=A0=A0 Pointers to some requirements listed in [RFC6434] are included in
=A0=A0 t=
his profile.=A0 The justification for using a stronger language<=
/span>
=A0=A0 compared to what is specified in=
 [RFC6434] is provided for some
=A0=A0 requirements.

 

If you thi= nk this is not clear, we can update the text to better clarify the logic.

 

4) REQ#2 title does not include IPv4, = but IPv4 PDP is mentioned in text:"in addition to the IPv4 PDP context= ." Does this mean IPv4 PDP context is also required, or is IPv4 PDP op= tional? Needs clarification.

[Med] The title focuses only on the IPv6-related PDP contexts. I don’= ;t think there is a value to use the normative language for IPv4 PDP.<= /o:p>

 

5) Is it required to be able to support di= fferent PDP types in parallel, e.g. IPv4 in parallel with IPv4v6? That prob= ably is (e.g. IPv4 for MMS, IPv4v6 for Internet), but do you wish to write = it down?

[Med] IMHO, this is = not specific to IPv6. I don’t think there is a value to explicit this= for IPv6-related PDP contexts.

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier New";color= :#1F497D'> 

6) RE= Q#3 says device MUST request IPv4v6 if the cellular host is dual-stack. Wel= l, this is how 3GPP writes it as well... but in reality all this depends on= provisioning. So you should say that this is the way, unless provisioned t= o do otherwise..

[Med] Would = you be OK if the text is changed as follows:

 

OLD:

the cel= lular host MUST request …

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier New";color= :#1F497D'> 

NEW:<= o:p>

the cellular host MUS= T request by default …

 

7) REQ#3= bullet 1, I don't follow. It says that if network does not have IPv4v6, bu= t "IPv4 and IPv6", then the network will configure IPv4 address a= nd IPv6 prefix. This is does not tell really much, IPv4 address and IPv6 pr= efix are provided if IPv4v6 is supported, or if IPv4 and IPv6 are allowed i= n parallel. Maybe this gets fixed if you change "and/or" to just = "or". Because if network gives only IPv4 or IPv6, then the device= can ask for parallel bearer.

[Med] Fixed.=

 

8) REQ#3 bullet 1: I would change the MAY open i= nitiate another PDP to SHOULD or MUST. This is because device is dual-stack= capable, has requested IPv4v6, but only gotten IPv4 or IPv6. If the networ= k does not indicate "single bearer only", then IMHO the device MU= ST ask for parallel PDP - which the network can reject. I.e. dual-stack hos= t should ask for IPv4v6, then IPv4 and IPv6 in parallel. Exceptions are pro= visioning or error codes available at and after release-8.

[Med] The text will be fixed.

 

9) REQ#4: What about RFC6106? I would think that cou= ld be MAY/SHOULD in addition to MUST for PCO option support.

=

[Med] This is discussed in REQ#9. No?<= /o:p>

 

10) REQ#6: should you clarify that MTU opt= ion really needs to be received and acted upon?

[Med] Can you explicit what change you want to see added= to the text?

&nb= sp;

11) = REQ#9 says in title "must" but in text "SHOULD". Which = way do you intend? I could go for MUST in order to allow more flexib= ility in the future, but SHOULD is ok as well

 

12) REQ#10 says in title "must", but = why? What if device just does not need anything via stateless DHCPv6? SHOUL= D would be better?

[Me= d] Idem as above.

 

13) The DNS discove= ry is split into REQ#4, REQ#9, and REQ#10. The REQ#10 is the only that says= preference order (with PCP, should probably be PCO instead). Could these R= EQs be combined? Should the preference order be a separate requirement ?

[Med] Fixed the typo with PCP. = OK to have a separate requirement for the preference order.

 

14) REQ#11 do you have requirement

<= p class=3DMsoNormal>[Med] See the justification text and also th= e DNSSEC case.

&n= bsp;

15) REQ#13 could have = pointer/dependency to REQ#11? I take DNSSEC support goes off-scope - but ne= vertheless REQ#13 is needed only if device supports DNSSEC, or 464XLAT?

[Med] Added a pointer to REQ#11.=

 

16) REQ#15 refers= to MIF - I would probably simply drop the MIF reference out, as if MIF is = included also other problems start creeping in (specific routes, DNS select= ion, provisioning domains...) - i.e. better exclude MIF problematics from t= his document. You could explicitly state whether you prefer DNS comm= unications to use IPv4 or IPv6 in dual-stack scenarios, as that seems to be= something currently more or less random.

[Med] No problem to remove the MIF reference. For the DNS case= , are you suggesting to add a sentence such as:

“When both IPv4 and IPv6 DNS servers are c= onfigured, a dual-stack host MUST contact first its IPv6 DNS server.”=

 

17) Section 2.1 I would like clarifi= cation whether this applies to "downlink" WiFi, "uplink"= ; WiFi, or both. It sounds like about uplink, but please spell it out.=

[Med] What difference do you make= between those two?

 

18) WiFi is a tra= demark owned by WiFi Alliance. Based on prior feedback to me, I would rathe= r talk about IEEE 802.11, or WLAN here as well.

[Med] Fixed. Thanks.

&nb= sp;

19) REQ#19 I would remo= ve the background text about "some recent tests revealed" on some= OS - it just does not suit well for profile document living for a looong t= ime. Alternatively you could have Appendix that includes some of the real-w= orld experiences of particular implementations?

[Med] We put that text there to record the encountered i= ssue with some implementations. If the requirement is supported, this would= n’t be an issue. I will discuss with my co-author how to handle this = comment. Thanks.

 

20) REQ#22 why this= is advanced requirement? I would call it basic.. and I would like to empha= size capability to receive MTU option via RA.

 

21) REQ#23 - I am not convinced full RFC4941 is always required. <= /span>Enough private  addresses could be obtained by simpler ways as w= ell, I believe. Hence I would rephrase that hosts MUST have RFC4941 or othe= r means for providing privacy addressing. I.e. the requirement should be ab= out privacy addresses, not RFC4941.

[Med] Makes sense. What about this change?

 

OLD:

 

The cellular host must comp=
ly with Section 5.9.3 of
<=
span class=3DMsoHyperlink>=A0=A0=A0=A0=A0=A0=A0=A0=A0 [RFC6434] for the support of the Privacy Extensions fo=
r
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 Stateless Address Autoconfiguration in IPv6.

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The activation of privacy extens=
ion makes it more difficult
=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to track a host over time when compare=
d to using a
=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 permanent interface identifier.=A0 [RFC49=
41] does not require
<= pre>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 any DAD mechani= sm to be activated as the GGSN (or PDN-GW)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MUST NOT configure any =
global address based on the prefix
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 allocated to the cellular hos=
t.

 =

NEW:

 

The cellular host MUST be able able to generate IPv6 addresses which pre=
serve privacy.

=  

=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 The activation of privacy extension (e.g., using [RF=
C4941]) makes it more difficult
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to t=
rack a host over time when compared to using a
=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 permanent interface=
 identifier. Note, [RFC4941] does=
 not require
=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0any DAD mechanism to be activated as the GGSN (or P=
DN-GW)
=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 MUST NOT configure any global address based on the prefix
=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 allocated to the cellular host.

 

 

22) RE= Q#24 is too ambiguous. Please state which ROHC profiles. AFAIK VoLTE requir= es RTP/UDP/IP, but nobody is requiring TCP profile (because for (Voice)/RTP= /UDP/IP the savings in compressed headers are significant, but for TCP bulk= download the savings are insignificant and when compared to overall costs = (cost of compressing/decompressing) probably close to negative). =

[Med] This is a very good point. = I do personally agree with you. Let see what there other think, if no objec= tion is raised, we will adopt your suggestion.

 

23) Section 4 title - please clarify this is downlink LAN 

24) RE= Q#27 makes 3GPP-wise sense only on Release-10 based networks. Do you= intent this requirement to cover all IPv6 hosts from 3GPP Release-99 onwar= ds (cherry picking)? Please clarify in either case.

[Med] Just like REQ#29, the tone has been softened = to not mention any 3GPP release as discussed here: http://www.ietf.org/mail-archive/web/v6ops/current/ms= g15742.html.

 

2= 5) REQ#33 this is something handset vendors have only so much control over.= . but maybe this document can also be given for application writers?-)=

[Med] I was aware of applications= developed by the same mobile device vendor but are not IPv6-compatible. Th= e requirement as currently worded is valid for all applications.=

 

&nbs= p;

Best regards,=

 

Teemu

&nbs= p;

 

 

<= div>

2013/3/27 <mohamed.boucadair@orange.com>

Dear all,

The changes in the new version = are as follows:

(1) Tweak the text in the Abstract and Introduction = to answer to the comment raised by F. Baker here: http:= //www.ietf.org/mail-archive/web/v6ops/current/msg15672.html
(2) Soft= en the tone for REQ#29 as discussed with Mickael here: = http://www.ietf.org/mail-archive/web/v6ops/current/msg15742.html
(3)= Add a disclaimer some features require activating some functions at the ne= twork side as suggested by Jouni
(4) Add an explicit reference to RFC643= 4 + whenever needed, indicate whether the new language form is stronger + J= ustification.

The new version integrates all the comments received s= o far.

Cheers,
Med

>-----Message d'origine-----
>= De : v6ops-bounces@ietf.org [= mailto:v6ops-bounces@ietf.org= ] De
>la part de internet= -drafts@ietf.org
>Envoy=E9 : mercredi 27 mars 2013 10:33
>= =C0 : i-d-announce@ietf.org>Cc : v6ops@ietf.org
>Objet= : [v6ops] I-D Action:
>draft-ietf-v6ops-mobile-device-profile-01.txt=

>
>
>A New Int= ernet-Draft is available from the on-line
>Internet-Drafts directorie= s.
> This draft is a work item of the IPv6 Operations Working
>= Group of the IETF.
>
>       Title    =       : Internet Protocol Version 6 (IPv6)
>Profile f= or Mobile Devices
>       Author(s)     &nbs= p; : David Binet
>               &= nbsp;          Mohamed Boucadair
>   &n= bsp;                     =  Ales Vizdal
>               =            Cameron Byrne
>    = ;                     &nb= sp;Gang Chen
>       Filename       &nb= sp;: draft-ietf-v6ops-mobile-device-profile-01.txt
>     &n= bsp; Pages           : 16
>     &n= bsp; Date            : 2013-03-27
>
= >Abstract:
>   This document specifies an IPv6 profile for mo= bile devices.
> It lists
>   the set of features a mobile = device is to be compliant with to
>   connect to an IPv6-only or= dual-stack mobile network.
>
>   This document defines a = different profile than the one for general
>   connection to IPv= 6 mobile networks defined in [RFC3316].  In
>   particular,= this document identifies also features to ensure IPv4
>   servi= ce continuity over an IPv6-only transport.
>
>   Both Host= s and devices with LAN capabilities are in scope.
>
>
>Th= e IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-pr= ofile
>
>There's also a htmlized version available at:
&= gt;http://tools.ietf.org/html/draft-ietf-v6ops-mobi= le-device-profile-01
>
>A diff from the previous version is= available at:
>http://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-v6ops-mobile-device
>-profile-01
>
>>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.o= rg/internet-drafts/
>
>____________________________________= ___________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops
>
_______________________________________________
v6ops maili= ng list
v6ops@ietf.org
https://= www.ietf.org/mailman/listinfo/v6ops

 

= --_000_94C682931C08B048B7A8645303FDC9F36EC73F1B67PUEXCB1Bnante_-- From jouni.nospam@gmail.com Fri Apr 19 01:08:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DB621F9367 for ; Fri, 19 Apr 2013 01:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKTXJ3prpH1R for ; Fri, 19 Apr 2013 01:08:03 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7324321F937B for ; Fri, 19 Apr 2013 01:08:02 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fs13so2577903lab.36 for ; Fri, 19 Apr 2013 01:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=TVMLO8VFIslIaHrCJEIH53pOumFyOX7hkspSpViifsM=; b=z8iICYJFOF9JEfW+Hrf/3myo5PRVVgavH2lhGEz9UFQTjHnen70EASL+gkx8GjtFbe pIj6WxCTtJNyjWyLDyS1/cZ0MB7QVPpcFlBbMuDZ5OtDrqvfnHTUcwPdTXYtmCeGypzY 5dMQHrB9RXhAOyE0ydxanoyN09x+6PbTf5Y74/KzfPiqE+d9LchZAvig/XgJHGYZaQ64 n9nCOEoqrXU0XEtSIkekLJAud1LzSww3Trco/dlSyNkGESadO3fgEfpXHuLOngMrWclJ QnyfTkGkkSNyehoWmxFtrFX4eXElgxXZG1xSgfvf/x0CFUPdH0EvvSVFPBtbAkkY8GHj aEng== X-Received: by 10.152.6.194 with SMTP id d2mr3752711laa.39.1366358879262; Fri, 19 Apr 2013 01:07:59 -0700 (PDT) Received: from [192.168.250.95] ([194.100.71.98]) by mx.google.com with ESMTPS id mq7sm5618534lab.1.2013.04.19.01.07.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Apr 2013 01:07:58 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5A51380D-F0A0-4D53-979A-666BB71367A8@gmail.com> Date: Fri, 19 Apr 2013 11:07:58 +0300 To: "v6ops@ietf.org Operations" , draft-ietf-v6ops-mobile-device-profile@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [v6ops] Review of draft-ietf-v6ops-mobile-device-profile-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 08:08:04 -0000 Hi, I did a review of draft-ietf-v6ops-mobile-device-profile-01. Below are my comments. They are rather long, sorry about that ;) - JOuni --------------------------------------------------------------------- 1) General notes o The I-D mixes (throughout) PDP context, PDP Context, PDP-Context. suggest to use PDP-Context. (I have not noted any of those in the comments below) o The I-D mixes (throughout) dual-stack and dual stack. Suggest to choose one style; like dual-stack. (I have not noted any of those in the comments below) o The I-D uses both RFC3316 and draft-ietf-v6ops-rfc3316bis. Suggest to use only the latter one. o The I-D uses a "mobile device" in places where it should really say a "cellular device". Use consistent wording. o The I-D uses a "mobile network" where it should really use "cellular network". In places where the network can be cellular or some other wireless technology, I would use "wireless network" as a generic term. o The use of GGSN and PDN-GW should have more consistency. For example using GGSN/PGW throughout.. 2) Abstract This document specifies an IPv6 profile for mobile devices. It lists ^^^^^^^^^^^^^^ the set of features a mobile device is to be compliant with to ^^^^^^^^^^^^^ o The document really is more about cellular devices than arbitrary mobile device. Suggest to reword "cellular devices". connect to an IPv6-only or dual-stack mobile network. ^^^^^^^^^^^^^^ o Since both cellular and Wi-Fi network are in scope, maybe saying "wireless networks" would be more appropriate? This document defines a different profile than the one for general connection to IPv6 mobile networks defined in [RFC3316]. In ^^^^^^^^^^^^^^^ ^^^^^^^^^ o RFC3316 is about cellular network. Even the RFC title says that. o Use RFC3316bis reference rather than RFC3316. particular, this document identifies also features to ensure IPv4 service continuity over an IPv6-only transport. ^^^^^^^^^^^^^^^^^^ o Service continuity is IMHO overloaded in IPv6 space with Mobile IPv6 and similar. Suggest to use "service availability". 3) Section 1 - Introduction IPv6 deployment in mobile networks is the only perennial solution to ^^^^^^^^^^^^^^^ o Suggest to use wireless networks. operators already deployed IPv6 or are in the pre-deployment phase. ^^^^^^^^ o "..have already deployed.." Some vendors are already proposing some mobile devices with a set of ^^^^^^^^^^^^^^ o Suggest using cellular devices. Some vendors are already proposing some mobile devices with a set of IPv6 features, but the majority of devices are still lacking IPv6 support. o For a profile or requirements, I would remove text like this since in few years time it will be outdated. Rather reword it stating the fact that cellular devices plain need to have IPv6 enabled if they don't already have it. connection to IPv6 mobile networks defined in [RFC3316]; in ^^^^^^ ^^^^^^^^ ... implement basic IPv6 features in a mobile context. ^^^^^^^ o s/mobile/cellular. And reference to RFC3316bis o It identifies also features to ensure IPv4 service continuity over ^^^^^^^^^^^^^^^^^^ o Suggest using "service availability" to make a clear distinction to IP mobility.. required specifications produced by various SDOs (in particular 3GPP ^^^^ o Expand SDO on the first occurrence. IPv6 connectivity and IPv4 service continuity (over an IPv6- only ^^^^^^^^^^ o s/IPv6- only/IPv6-only 4) Section 1.1 - Scope user equipment such as a mobile telephone, a CPE or a machine-to- ^^^^ o Expand CPE on the first occurrence. The requirements listed below are valid for both 3GPP GPRS and 3GPP EPS access. For EPS, "PDN type" terminology is used instead of "PDP ^^^ ^^^^^^^^ context". o Expand EPS on the first use and give a reference. o I assume this is supposed to be "PDN-Connection" not "PDN Type" ?? o Expand GPRS on the first use. 5) Section 2 - Connectivity Requirements REQ#2: The cellular host MUST support both IPv6 and IPv4v6 PDP Contexts. o for a MUST requirement I would like to see the 3GPP release to which this applies. o there are also cases where IPv6-only cellular host is justified, thus I would point back here in the text to e.g. Section 1.1 M2M scope clarification/narration. REQ#3: The cellular host MUST comply with the behavior defined in [TS.23060] [TS.23401] [TS.24008] for requesting a PDP context o The list of references neglect non-3GPP accesses (TS.23402). I am fine with that but you should state it in e.g. Section 1.1 scoping that non-3GPP accesses except for some exceptions (Wi-Fi without 3GPP flavour) are out of scope. the cellular host is not aware of connectivity types requested by devices connected to it (e.g., cellular host with LAN capabilities): o I would clarify this part of the text a bit more. The text in 3GPP standards are mostly coming from the Split-UE background where MT and TE are separate, not from tethering. Therefore, some rewording is needed here. As such the current text is not acceptable. cellular host will be configured with an IPv4 address and/or ^^^^^^^ o s/will be/MAY be. There is no guarantee that an UE would always open two PDPs. an IPv6 prefix by the network. It MAY initiate another PDP ^^^ request in addition to the one already activated for a given APN. ^^^^ o "PDP request" I would use different wording like "PDP-Context activation" o Expand APN on the first occurrence. Traffic Flow Templates are employing a Packet Filter to ^^^^^^^^^^^^^ o "packet filter" ? PDP-Context and radio resources can be provided by the mobile network for certain IP traffic. ^^^^^^ o s/mobile network/cellular network This is a stronger form compared to what is specified in Section 12.2 of [RFC6434]. The support of Neighbor Discovery ^^^^^^^^^^^^ o Section 5.2 should also be referenced here since e.g. RFC5942 is mentioned in there rather than in Section 12.2. In particular, MTU communication via Router Advertisement ^^^^ o Expand MTU on the first occurrence. standard MTU setting due to inconsistencies in GTP [RFC3314] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ o Expand GTP on the first occurrence. o It is unclear what the "inconsistencies in GTP" are. The RFC3314 definitely does not tell a thing about that. Also give a reference to a proper GTP specification(s). REQ#8: The cellular host MUST support IPv6 Stateless Address Autoconfiguration ([RFC4862]) apart from the exceptions noted in [TS.23060] (3G) and [TS.23401] (LTE): ^^^^^^^^^^^ ^^^^ ^^^^ o What are the exceptions? If you mean the restrictions in 3GPP SLAAC point to other documents like RFC6459 or RFC3316bis that detail those out. o s/3G/GPRS o s/LTE/EPS The cellular host MUST use the interface identifier sent in ^ ^ o s/interface identifier/Interface Identifier. For the consistency.. PDP Context Accept message to configure its link local ^^^^^^^^^^^^^^^^^^^^^^^^^^ o Suddenly referencing to specific 3GPP signaling messages seems odd here. I suggest to reword "3GPP PDP-Context setup signaling from a GGSN/PGW to the cellular host" or something to that direction. REQ#9: The cellular host must comply with Section 7.3 of [RFC6434]. ^^^^ o s/must/MUST o Generally about the "Req#9". The motivational text following the requirement title is not imho needed. The MUST for Section 7.3 of RFC6434 is quite clear. REQ#10: The cellular host must comply with Section 7.2.1 of ^^^^ o s/must/MUST 1. PCP ^^^^^^^ o I assume PCO is meant here? Translator (CLAT, [I-D.ietf-v6ops-464xlat]) function which is ^^^^^^^^^^^^^^^^^^^^^^^ o RFC6877 yay! application and IPv4-referals to work on an IPv6-only PDP. ^^^^^^^^^^^^^ o I suggest replacing PDP with "network" or "access network" or "PDP-Context". DNSSEC. Means to configure or discover a PREFIX64 is also ^^^^^^^ ^^^^^^^ required on the cellular device. ^^^^^^^^ o Add a reference to DNSSEC. o Pref64 discovery is already SHOULDed in Req11. Mentioning it here again seems unnecessary repetition. The support of PCP is seen as a driver to save battery ^^^^^^^^^^^^^^^^^^^^^^ consumption exacerbated by keepalive messages. PCP also o This is a strong statement. Do we have documented proof of that? PCP itself does not solve or even help that much the battery savings since the host side applications still need to coordinate among themselves and it is a different issue & problem. REQ#15: When the cellular host is dual stack connected, it SHOULD ^^^^^^^^^^^^^^^^^^^^^ o Using what mechanisms? Two PDPs? IPv4v6 PDP or XLAT? Or should we actually not care? Some clarification would be nice here, though. [I-D.ietf-mif-happy-eyeballs-extension] for MIFed devices. ^^^^^ o Care to expand.. REQ#17: The cellular host SHOULD NOT perform Duplicate Address Detection (DAD) for these Global IPv6 addresses (as the GGSN or PDN-GW must not configure any IPv6 addresses using the prefix allocated to the cellular host). Refer to Section 4 for DAD considerations on the LAN interface when the 3GPP connection is shared. o This is already in RFC6459 and RFC 3316(bis). No need to repeat the requirement here again and Section 4 deals with the specific case that is not in the previously mentioned RFCs. I suggest removing the Req17. 6) Section 2.1 - Wi-Fi Connectivity 2.1. WiFi Connectivity ^^^^^^^^ o Why not adding "Requirements" here as well? REQ#19: IPv6 MUST be supported on the Wi-Fi interface. In particular, IPv6-only connectivity MUST be supported over the Wi-Fi interface. o Suggest rewording "..Wi-Fi interface without configuring IPv4 on the interface." Recent tests revealed that IPv4 configuration is required to enable IPv6-only connectivity. Indeed, some cellular handsets can access a Wi-Fi IPv6-only network by configuring first a static IPv4 address. Once the device is connected to the network and the wlan0 interface got an IPv6 global address, the IPv4 address can be deleted from the configuration. This avoids the device to ask automatically for a DHCPv4 server, and allows to connect to IPv6-only networks. o I would delete this and just state that "Failing to configure an IPv4 address on the interface MUST NOT prohibit using IPv6 on the same interface." 7) Section 3 - Advanced Requirements REQ#22: The cellular host must comply with Section 5.6.1 of ^^^^ o s/must/MUST REQ#23: The cellular host must comply with Section 5.9.3 of ^^^^ o s/must/MUST permanent interface identifier. [RFC4941] does not require any DAD mechanism to be activated as the GGSN (or PDN-GW) MUST NOT configure any global address based on the prefix allocated to the cellular host. REQ#24: The cellular host SHOULD support ROHC for IPv6 ([RFC5795]). o I would say which ROHC profiles SHOULD be supported. It makes no sense to require all, since IMHO ROHC has limited benefit in 3G/LTE. I would strongly recommend aligning this requirement to GSMA PRD.92. o IMHO no need to repeat the DAD behaviour. I strongly suggest removing the last sentence. This is a stronger form compared to what is specified in [RFC6434]. The justification is some flags are used by the GGSN (or PDN-GW) to inform cellular hosts about the autoconfiguration process. ^^^^^^^^^^^^^^^^^^^^^^^^^^ o Care to reveal the flags that do the justification? What are told now by GGSNs/PGWs more in extended flags? I am OK with the requirement as such but the justification text is just confusing. I suggest removing it. REQ#26: The cellular host must comply with Section 5.3 of [RFC6434] ^^^^ o s/must/MUST 8) Section 4 - Cellular Devices with LAN Capabilities 4. Cellular Devices with LAN Capabilities ^^^ o So this is strongly about LAN, not WLAN? are sharing the same GPRS, UMTS or EPS connection. In addition to ^^^^ ^^^^ ^^^ o s/GPRS/2G o s/UMTS/3G o s/EPS/LTE WAN and the Delegated Prefix to be aggregatable, so the ^^^ o Expand WAN on the first occurrence. (e.g., halving the Delegated prefix and assigning the WAN ^^^ o s/Delegated/delegated requirements specified in [RFC6204]. ^^^^^^^ o I would suggest referencing to RFC6204bis since it has some language that takes cellular network particularly into considerations. reduced to 1440 bytes. While a host may generate packets ^^^^^ o TS.23060 has specific MTU size recommendations. I would reference to that and also "reveal" the number stated in there. 9) Section 5 - APIs & Applications REQ#33: Applications MUST be independent of the underlying IP address family. o I think SHOULD/RECOMMENDED with some stressing would be more appropriate. There could be cases where IP version specific software is justified, e.g. diagnostic tools and such.. Maybe "MUST be independent of the underlying IP address family, unless done purposely address family specific for a specific reasons." 10) Section 6 - Security Considerations The security considerations identified in [RFC3316] are to be taken ^^^^^^^^^ o Use RFC3316bis and also reference to RFC6459 that has some additional security considerations to RFC3316. From tsavo.stds@gmail.com Mon Apr 22 02:51:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C374421E803D for ; Mon, 22 Apr 2013 02:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JklyjxaJjHQV for ; Mon, 22 Apr 2013 02:51:07 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2060E11E809C for ; Mon, 22 Apr 2013 02:51:05 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hj19so3989202wib.15 for ; Mon, 22 Apr 2013 02:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q2AKYKM2iPswbRaq7f5bmrBijP8SaF3T5d8qMxMFiIU=; b=hQT95gR/rBmqR4sp/pcZjG20EzCofeprHVHU2W6Ui3Ppea23jHI34x8myKvhmE/0GS nN/vNRUHP2RWJcaKWmtMXLS8OSzOxHY0Na7k1uprC4dGIvrR2jdg+WOmFoLy/UpmNLG0 Mp44x2m0t0CsjgHUcUuc+2hPyBpQrsiv5FqKmWhICJKDS1tNPfRFkANBzi8J3bVh062t HJDP+/o2LGFxwnz1+QJku2t8qbAW+ICO6+jUp4qqpLb4hCg0lyDXz9EV3HWMfi1y1ZEu qx9Tgz6UY2gh+l3mBnTrL6w+7ETRJxj/KBvfspeFV5sls7I6DQJRF7BmaraapvapW768 vDEg== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr50466957wjc.35.1366624262856; Mon, 22 Apr 2013 02:51:02 -0700 (PDT) Received: by 10.194.152.71 with HTTP; Mon, 22 Apr 2013 02:51:02 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC73F1B67@PUEXCB1B.nanterre.francetelecom.fr> References: <20130327093238.29058.4046.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EBBE68FFC@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EC73F1B67@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 22 Apr 2013 12:51:02 +0300 Message-ID: From: Teemu Savolainen To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=089e013d1da8baa5cd04daf001a1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 09:51:15 -0000 --089e013d1da8baa5cd04daf001a1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Med, Thank you for your prompt reply, further comments inline for some points (rest cut): Cheers, Teemu 2) In my opinion all references to 3316 should be changed to > draft-ietf-v6ops-rfc3316bis, > > [Med] Will see how to update the text.**** > > ** ** > > and there is no need to compare RFC3316 with 3316bis draft in here (in > section 1), as the 3316bis will obsolete the 3316.**** > > [Med] Are you referring to this text?**** > > ** ** > > [RFC3316] lists a set of features to be supported by cellular hosts***= * > > to connect to 3GPP cellular networks. Since the publication of that**= * > * > > document, new functions have been specified within the 3GPP and the***= * > > IETF whilst others have been updated. Moreover, in the light of**** > > recent IPv6 production deployments, additional features to facilitate*= * > ** > > IPv6-only deployments while accessing IPv4-only service are to be**** > > considered.**** > > ** ** > > Are you suggesting this text is to be removed? **** > > ** > What I'm saying is that RFC3316bis will obsolete RFC3316, hence this document should not be referring to obsolete RFC - assuming both these complete roughly at the same time. Hence you should replace the RFC3316 with RFC3316bis and modify the text accordingly. I.e. describe what this document brings in addition. Maybe something like: [RFC3316bis] lists a set of features to be supported by cellular hosts**= * * to connect to 3GPP cellular networks. In the light of recent IPv6 production deployments, additional features to facilitate***= * IPv6-only deployments while accessing IPv4-only service are to be**** considered. or something? > 3) Why some of the requirements of RFC6434 are duplicated herein with sam= e > keywords, e.g. REQ#1 has MUST for same thing RFC6434 has MUST. I would > suppose a profile document could say that mobile device MUST follow > RFC6434, except when ? > > ** > > [Med] Isn=92t this covered by this text:**** > > ** ** > > Pointers to some requirements listed in [RFC6434 ] are included in**** > > this profile. The justification for using a stronger language**** > > compared to what is specified in [RFC6434 ] is provided for some**** > > requirements.**** > > If you think this is not clear, we can update the text to better clarify > the logic. > > ** > Well I just don't see why to point to some requirements in RFC6434, except to use stronger (or weaker) language for the requirements explicitly pointed at. Could the document perhaps state that RFC6434 is required but with exceptions and additions listed in this document? > 4) REQ#2 title does not include IPv4, but IPv4 PDP is mentioned in > text:"in addition to the IPv4 PDP context." Does this mean IPv4 PDP conte= xt > is also required, or is IPv4 PDP optional? Needs clarification. > > ** > > [Med] The title focuses only on the IPv6-related PDP contexts. I don=92t > think there is a value to use the normative language for IPv4 PDP.**** > > I was asking because the "Both IPv6 and IPv4v6 PDP contexts MUST be supported in addition to the IPv4 PDP." sounds like normative text. I was thinking whether this document allows a device with just IPv6 and IPv4v6 PDP context support. Probably no use for such device in near future, but I was nevertheless wondering if IPv4 is explicitly required. > 5) Is it required to be able to support different PDP types in parallel, > e.g. IPv4 in parallel with IPv4v6? That probably is (e.g. IPv4 for MMS, > IPv4v6 for Internet), but do you wish to write it down?**** > > [Med] IMHO, this is not specific to IPv6. I don=92t think there is a valu= e > to explicit this for IPv6-related PDP contexts. > True, ok for me not to talk about this here. > 6) REQ#3 says device MUST request IPv4v6 if the cellular host is > dual-stack. Well, this is how 3GPP writes it as well... but in reality al= l > this depends on provisioning. So you should say that this is the way, > unless provisioned to do otherwise..**** > > [Med] Would you be OK if the text is changed as follows: > > OLD:**** > > the cellular host MUST request =85 > > NEW:**** > > the cellular host MUST request by default =85 > Yes, that would be fine. > 9) REQ#4: What about RFC6106? I would think that could be MAY/SHOULD in > addition to MUST for PCO option support.**** > > [Med] This is discussed in REQ#9. No? > True, probably by the time I hit REQ#9 I had forgotten this comment already:) > 10) REQ#6: should you clarify that MTU option really needs to be received > and acted upon?**** > > [Med] Can you explicit what change you want to see added to the text? > MTU communication via RA from SHOULD to MUST? > 11) REQ#9 says in title "must" but in text "SHOULD". Which way do you > intend? I could go for MUST in order to allow more flexibility in the > future, but SHOULD is ok as well**** > > [Med] =93must comply=94 with Section 7.3 means it needs to follow what is > described in that section: i.e., SHOULD support 6106. This is indicated > explicitly in the text. > What does it mean when one "must comply" with "SHOULD"?-) If the normative text says SHOULD, why the title could not be "The cellular host should comply with.." > 12) REQ#10 says in title "must", but why? What if device just does not > need anything via stateless DHCPv6? SHOULD would be better?**** > > [Med] Idem as above. > And same as above, "must comply" with "SHOULD" is confusing. > 14) REQ#11 do you have requirement **** > > [Med] See the justification text and also the DNSSEC case. > This was a typo from me, I thought of something, checked it out, and then forgot to delete the text I had started writing... > 16) REQ#15 refers to MIF - I would probably simply drop the MIF reference > out, as if MIF is included also other problems start creeping in (specifi= c > routes, DNS selection, provisioning domains...) - i.e. better exclude MIF > problematics from this document. You could explicitly state whether you > prefer DNS communications to use IPv4 or IPv6 in dual-stack scenarios, as > that seems to be something currently more or less random. > > ** > > [Med] No problem to remove the MIF reference. For the DNS case, are you > suggesting to add a sentence such as: **** > > =93When both IPv4 and IPv6 DNS servers are configured, a dual-stack host > MUST contact first its IPv6 DNS server.=94 > Yes, that would suit me, but I wanted to check whether you wish it that way, or if "random" is ok (or e.g. happy eyeballs style approach). > 17) Section 2.1 I would like clarification whether this applies to > "downlink" WiFi, "uplink" WiFi, or both. It sounds like about uplink, but > please spell it out.**** > > [Med] What difference do you make between those two? > Never mind, I was thinking perhaps a bit too far. It talks already about hotspots anyway. > 19) REQ#19 I would remove the background text about "some recent tests > revealed" on some OS - it just does not suit well for profile document > living for a looong time. Alternatively you could have Appendix that > includes some of the real-world experiences of particular implementations= ? > > ** > > [Med] We put that text there to record the encountered issue with some > implementations. If the requirement is supported, this wouldn=92t be an > issue. I will discuss with my co-author how to handle this comment. Thank= s. > I'm fine with the requirement, but if you need to keep it for a while still that's ok. > 20) REQ#22 why this is advanced requirement? I would call it basic.. and = I > would like to emphasize capability to receive MTU option via RA.**** > > [Med] Would moving this REQ to be called out just after REQ#6 be OK with > you? > Yes. > 21) REQ#23 - I am not convinced full RFC4941 is always required. Enough > private addresses could be obtained by simpler ways as well, I believe. > Hence I would rephrase that hosts MUST have RFC4941 or other means for > providing privacy addressing. I.e. the requirement should be about privac= y > addresses, not RFC4941.**** > > [Med] Makes sense. What about this change?**** > > ** OLD: > > ** The cellular host must comply with Section 5.9.3 of > > [RFC6434] fo= r the support of the Privacy Extensions for**** > > Stateless Address Autoconfiguration in IPv6.**** > > ** ** > > The activation of privacy extension makes it more difficult*= *** > > to track a host over time when compared to using a**** > > permanent interface identifier. [RFC4941 ] does not require**** > > any DAD mechanism to be activated as the GGSN (or PDN-GW)***= * > > MUST NOT configure any global address based on the prefix***= * > > allocated to the cellular host.**** > > ** NEW: > > ** The cellular host MUST be able able to generate IPv6 addresses which > preserve privacy. > > ** ** > > The activation of privacy extension (e.g., using [RFC4941 ]) makes it more difficult**** > > to track a host over time when compared to using a**** > > permanent interface identifier. Note, [RFC4941 ] does not require**** > > any DAD mechanism to be activated as the GGSN (or PDN-GW)***= * > > MUST NOT configure any global address based on the prefix***= * > > allocated to the cellular host. > > Would work for me. --089e013d1da8baa5cd04daf001a1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Med,

Thank you for your prompt reply= , further comments inline for some points (rest cut):

<= div>Cheers,

Teemu

2) In my opinion all references to 3316 should be changed to draft-i= etf-v6ops-rfc3316bis,

[Med] Will see how t= o update the text.

= =A0

and there is no need to compare RFC3316 = with 3316bis draft in here (in section 1), as the 3316bis will obsolete the= 3316.

=A0

=A0=A0 [RFC3316] l= ists a set of features to be supported by cellular hosts

=A0=A0 to connect to 3GPP cellular networks.=A0 Since th= e publication of that

=A0=A0 doc= ument, new functions have been specified within the 3GPP and the<= /u>

=A0=A0 IETF whilst others have been updated.=A0 Moreover= , in the light of

=A0=A0 recent = IPv6 production deployments, additional features to facilitate

=A0=A0 IPv6-only deployments while accessing IPv4-only s= ervice are to be

=A0=A0 <= span style=3D"font-size:10pt;font-family:'Courier New'">considered.=

=A0

Are you suggesting this text is to be remo= ved?


What I'm saying is that R= FC3316bis will obsolete RFC3316, hence this document should not be referrin= g to obsolete RFC - assuming both these complete roughly at the same time. = Hence you should replace the RFC3316 with RFC3316bis and modify the text ac= cordingly. I.e. describe what this document brings in addition. Maybe somet= hing like:

=A0 =A0[RFC3316bis] lists a set of features to be supp= orted by cellular hosts

=A0=A0 to connect to 3GPP cellular networks. =A0I<= /span>n th= e light of

=A0=A0 recent IPv6 production deployments, additional fe= atures to facilitate

=A0=A0 IPv6= -only deployments while accessing IPv4-only service are to be=

=A0=A0=A0considered.

or somethin= g?=A0

3) = Why some of the requirements of RFC6434 are duplicated herein with same key= words, e.g. REQ#1 has MUST for same thing RFC6434 has MUST. I would suppose= a profile document could say that mobile device MUST follow RFC6434, excep= t when <exceptions> ?

[Med] Isn=92t this covered by this text:

=A0

=A0=A0 Pointers to some requirements listed in [<=
a href=3D"http://tools.ietf.org/html/rfc6434" title=3D""IPv6 Node Requ=
irements"" target=3D"_blank">RFC6434] are included in
=A0=A0 this profile.=A0 The justification for usi=
ng a stronger language
=
=A0=A0 compared to what is specified in [RFC6434] is pr=
ovided for some
=A0=A0 requirements.
If you think this is not clear, we can update the te= xt to better clarify the logic.

<= /div>
Well I just don't see why to point to some= requirements in RFC6434, except to use stronger (or weaker) language for t= he requirements explicitly pointed at.=A0

Could the document perhaps state that RFC64= 34 is required but with exceptions and additions listed in this document?
=A0

4) = REQ#2 title does not include IPv4, but IPv4 PDP is mentioned in text:"= in addition to the IPv4 PDP context." Does this mean IPv4 PDP context = is also required, or is IPv4 PDP optional? Needs clarification.

[Med] The title focuses only on the IPv6-relat= ed PDP contexts. I don=92t think there is a value to use the normative lang= uage for IPv4 PDP.

=
I was asking because the "Both IPv6 and IPv4v6 PDP=A0contexts MUST be supported in addition to = the IPv4 PDP.&= quot; sounds like normative text. =A0I was thinking whether =A0this documen= t allows a device with just IPv6 and IPv4v6 PDP context support. Probably n= o use for such device in near future, but I was nevertheless wondering if I= Pv4 is explicitly required.

5) Is it required to be able to suppor= t different PDP types in parallel, e.g. IPv4 in parallel with IPv4v6? That = probably is (e.g. IPv4 for MMS, IPv4v6 for Internet), but do you wish to wr= ite it down?

[Med] IMHO, this is not speci= fic to IPv6. I don=92t think there is a value to explicit this for IPv6-rel= ated PDP contexts.

True, ok for me not to talk about= this here.=A0

6) REQ#3 says device MUST= request IPv4v6 if the cellular host is dual-stack. Well, this is how 3GPP = writes it as well... but in reality all this depends on provisioning. So yo= u should say that this is the way, unless provisioned to do otherwise..<= /u>

[Med] Would you be OK if the = text is changed as follows:

OLD:

the cellular host MUST request =85=

NEW:

the cellular host MUST request by = default =85

Yes, that would b= e fine.
=A0

9) REQ#4: What about RFC6106? I would = think that could be MAY/SHOULD in addition to MUST for PCO option support.<= u>

[Med] This i= s discussed in REQ#9. No?

True, probably by the time I hit = REQ#9 I had forgotten this comment already:)
=A0

10) REQ#6: should yo= u clarify that MTU option really needs to be received and acted upon?

[Med] Can you explicit what c= hange you want to see added to the text?

MTU communication via RA from SHOULD to MUST?
=A0

11) REQ#9 says in title "must" but in text "SHOULD". W= hich way do you intend? I could go for MUST in order to allow more flexibility in the future, but SHOULD is ok as well

[Med] =93must comply=94 with = Section 7.3 means it needs to follow what is described in that section: i.e= ., SHOULD support 6106. This is indicated explicitly in the text.

What does it mean when one "= must comply" with "SHOULD"?-) If the normative text says SHO= ULD, why the title could not be "The cellular host should comply with.."
=A0

12) REQ#10 says i= n title "must", but why? What if device just does not need anythi= ng via stateless DHCPv6? SHOULD would be better?

[Med] Idem as above.

And same as above, "must comply&= quot; with "SHOULD" is confusing.
=A0

14) REQ#11 do you have requirement =

[Med] See the = justification text and also the DNSSEC case.


This was a typo fr= om me, I thought of something, checked it out, and then forgot to delete th= e text I had started writing...=A0

16) REQ#15 refers to MIF - I would probably simply drop the MIF= reference out, as if MIF is included also other problems start creeping in= (specific routes, DNS selection, provisioning domains...) - i.e. better ex= clude MIF problematics from this document. You could explicitly state whether you prefer DNS communications = to use IPv4 or IPv6 in dual-stack scenarios, as that seems to be something = currently more or less random.

[Med] No problem to remove the MIF reference. = For the DNS case, are you suggesting to add a sentence such as: <= /u>

=93When both IPv4 and IPv6 DNS serv= ers are configured, a dual-stack host MUST contact first its IPv6 DNS serve= r.=94

Yes, that would suit me, but I wa= nted to check whether you wish it that way, or if "random" is ok = (or e.g. happy eyeballs style approach).
=A0

17) Section 2.1 I wo= uld like clarification whether this applies to "downlink" WiFi, &= quot;uplink" WiFi, or both. It sounds like about uplink, but please sp= ell it out.

[Med] What difference do you = make between those two?

Never mind, I was thinking perhaps a bit too far. It talks already about h= otspots anyway.
=A0

19) REQ#19 I would remove the backgrou= nd text about "some recent tests revealed" on some OS - it just d= oes not suit well for profile document living for a looong time. Alternativ= ely you could have Appendix that includes some of the real-world experience= s of particular implementations?

[Med] We put that text there to record t= he encountered issue with some implementations. If the requirement is suppo= rted, this wouldn=92t be an issue. I will discuss with my co-author how to = handle this comment. Thanks.

I'm fine with the requirement= , but if you need to keep it for a while still that's ok.
=A0=

20) REQ#22 why this = is advanced requirement? I would call it basic.. and I would like to emphas= ize capability to receive MTU option via RA.

[Med] Would moving this REQ t= o be called out just after REQ#6=A0be OK with you?

Yes.=A0

21) REQ#23 - I am not convinced full RFC4941 is= always required. Enough private =A0addresses could be obtained by s= impler ways as well, I believe. Hence I would rephrase that hosts MUST have= RFC4941 or other means for providing privacy addressing. I.e. the requirem= ent should be about privacy addresses, not RFC4941.

[Med] Makes sense. What about= this change?

=A0OLD:

=A0The cellular host must comply with Secti= on=A05.9.3 of

=A0=A0=A0=A0=A0=A0=A0=A0=A0 [RFC6434] for the support of the Privacy Extens=
ions for
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Stateless Address Aut=
oconfiguration in IPv6.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The activati=
on of privacy extension makes it more difficult
<= pre>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to track a ho= st over time when compared to using a 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 permanent in=
terface identifier.=A0 [RFC4941<=
span lang=3D"EN-US">] does not require
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 any DAD mech=
anism to be activated as the GGSN (or PDN-GW)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MUST NOT config= ure any global address based on the prefix 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 allocated to=
 the cellular host.

=A0NEW:

=A0The cellular host = MUST be able able to generate IPv6 addresses which preserve privacy.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The activation of privacy extensi=
on (e.g., using [RFC4941]) makes it more difficult
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to track a h=
ost over time when compared to using a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 permanent interface id=
entifier. Note, [RFC4941] does not require
=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0any DAD mech=
anism to be activated as the GGSN (or PDN-GW)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MUST NOT config= ure any global address based on the prefix 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 allocated to=
 the cellular host.

Would work for me.=A0
--089e013d1da8baa5cd04daf001a1-- From mohamed.boucadair@orange.com Mon Apr 22 23:08:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C2B21F965F for ; Mon, 22 Apr 2013 23:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrGodaKK5FUT for ; Mon, 22 Apr 2013 23:08:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B442321F9660 for ; Mon, 22 Apr 2013 23:08:09 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id AF60A18C1B9; Tue, 23 Apr 2013 08:08:07 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9347935C061; Tue, 23 Apr 2013 08:08:07 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 23 Apr 2013 08:08:07 +0200 From: To: Jouni Korhonen , "v6ops@ietf.org" Date: Tue, 23 Apr 2013 08:08:05 +0200 Thread-Topic: Review of draft-ietf-v6ops-mobile-device-profile-01 Thread-Index: Ac4/6OEC6YLwaoeNQVemAIHO0Qe09g== Message-ID: <94C682931C08B048B7A8645303FDC9F36EC86EB942@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.23.50322 Cc: "draft-ietf-v6ops-mobile-device-profile@tools.ietf.org" Subject: Re: [v6ops] Review of draft-ietf-v6ops-mobile-device-profile-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 06:08:11 -0000 Hi Jouni, Many thanks for the review. My answers inline. Cheers, Med >-----Message d'origine----- >De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] >Envoy=E9 : vendredi 19 avril 2013 10:08 >=C0 : v6ops@ietf.org Operations; draft-ietf-v6ops-mobile-device- >profile@tools.ietf.org >Objet : Review of draft-ietf-v6ops-mobile-device-profile-01 > >Hi, > >I did a review of draft-ietf-v6ops-mobile-device-profile-01. Below are >my comments. They are rather long, sorry about that ;) > >- JOuni > >--------------------------------------------------------------------- > >1) General notes > >o The I-D mixes (throughout) PDP context, PDP Context, PDP-Context. > suggest to use PDP-Context. (I have not noted any of those in > the comments below) [Med] Fixed. >o The I-D mixes (throughout) dual-stack and dual stack. Suggest > to choose one style; like dual-stack. (I have not noted any of [Med] Fixed. > those in the comments below) >o The I-D uses both RFC3316 and draft-ietf-v6ops-rfc3316bis. Suggest > to use only the latter one. [Med] The text will be tweaked. >o The I-D uses a "mobile device" in places where it should really say > a "cellular device". Use consistent wording. [Med] Will check the text. >o The I-D uses a "mobile network" where it should really use "cellular > network". In places where the network can be cellular or some other > wireless technology, I would use "wireless network" as a generic > term. [Med] The text twill be checked. >o The use of GGSN and PDN-GW should have more consistency. For example > using GGSN/PGW throughout.. [Med] OK. > >2) Abstract > > This document specifies an IPv6 profile for mobile devices. It lists > ^^^^^^^^^^^^^^ > the set of features a mobile device is to be compliant with to > ^^^^^^^^^^^^^ [Med] changed to "This document specifies an IPv6 profile for 3GPP mobile d= evices. It lists the set of features a 3GPP mobile device is to be complian= t with to connect to an IPv6-only or dual-stack wireless network (including= 3GPP cellular network and IEEE 802.11 network)." > >o The document really is more about cellular devices than arbitrary > mobile device. Suggest to reword "cellular devices". [Med] As suggested by Teemu, "3GPP mobile devices" is used instead. > > connect to an IPv6-only or dual-stack mobile network. > ^^^^^^^^^^^^^^ >o Since both cellular and Wi-Fi network are in scope, maybe > saying "wireless networks" would be more appropriate? [Med] See the proposed change above. > > This document defines a different profile than the one for general > connection to IPv6 mobile networks defined in [RFC3316]. In > ^^^^^^^^^^^^^^^ ^^^^^^^^^ >o RFC3316 is about cellular network. Even the RFC title says that. >o Use RFC3316bis reference rather than RFC3316. [Med] Will check the text and update when appropriate. > > particular, this document identifies also features to ensure IPv4 > service continuity over an IPv6-only transport. > ^^^^^^^^^^^^^^^^^^ >o Service continuity is IMHO overloaded in IPv6 space with > Mobile IPv6 and similar. Suggest to use "service availability". [Med] changed the wording to "deliver IPv4 connectivity service". > >3) Section 1 - Introduction > > IPv6 deployment in mobile networks is the only perennial solution to > ^^^^^^^^^^^^^^^ >o Suggest to use wireless networks. [Med] OK. > > operators already deployed IPv6 or are in the pre-deployment phase. > ^^^^^^^^ >o "..have already deployed.." [Med] Fixed. > > Some vendors are already proposing some mobile devices with a set of > ^^^^^^^^^^^^^^ >o Suggest using cellular devices. > > Some vendors are already proposing some mobile devices with a set of > IPv6 features, but the majority of devices are still lacking IPv6 > support. > >o For a profile or requirements, I would remove text like this > since in few years time it will be outdated. Rather reword it > stating the fact that cellular devices plain need to have IPv6 > enabled if they don't already have it. [Med] Makes sense. Removed. > > connection to IPv6 mobile networks defined in [RFC3316]; in > ^^^^^^ ^^^^^^^^ > ... > implement basic IPv6 features in a mobile context. > ^^^^^^^ >o s/mobile/cellular. And reference to RFC3316bis [Med] Fixed. > > o It identifies also features to ensure IPv4 service continuity over > ^^^^^^^^^^^^^^^^^^ >o Suggest using "service availability" to make a clear distinction > to IP mobility.. [Med] Changed to "IPv4 service delivery" > > required specifications produced by various SDOs (in particular 3GPP > ^^^^ >o Expand SDO on the first occurrence. [Med] Fixed. > > IPv6 connectivity and IPv4 service continuity (over an IPv6- only > ^^^^^^^^^^ >o s/IPv6- only/IPv6-only [Med] Fixed. > >4) Section 1.1 - Scope > > user equipment such as a mobile telephone, a CPE or a machine-to- > ^^^^ >o Expand CPE on the first occurrence. [Med] Fixed. > > The requirements listed below are valid for both 3GPP GPRS and 3GPP > EPS access. For EPS, "PDN type" terminology is used instead of "PDP > ^^^ ^^^^^^^^ > context". > >o Expand EPS on the first use and give a reference. >o I assume this is supposed to be "PDN-Connection" not "PDN Type" ?? >o Expand GPRS on the first use. [Med] Fixed. I didn't cited any ref as the document already points to RFC64= 59. > >5) Section 2 - Connectivity Requirements > > REQ#2: The cellular host MUST support both IPv6 and IPv4v6 PDP > Contexts. > >o for a MUST requirement I would like to see the 3GPP release to > which this applies. [Med] Like for other requirements, we avoided to mention the release as sug= gested by Mickael (check the v6ops ml archives). >o there are also cases where IPv6-only cellular host is justified, > thus I would point back here in the text to e.g. Section 1.1 > M2M scope clarification/narration. > > REQ#3: The cellular host MUST comply with the behavior defined in > [TS.23060] [TS.23401] [TS.24008] for requesting a PDP context > >o The list of references neglect non-3GPP accesses (TS.23402). I am fine > with that but you should state it in e.g. Section 1.1 scoping that > non-3GPP accesses except for some exceptions (Wi-Fi without 3GPP > flavour) are out of scope. Med: Section 1.1 states explicitly both 3GPP accesses and WLAN are in scope= . No need to have an explicit reference to TS.23402. > > the cellular host is not aware of connectivity types requested > by devices connected to it (e.g., cellular host with LAN > capabilities): > >o I would clarify this part of the text a bit more. The text in 3GPP > standards are mostly coming from the Split-UE background where MT and > TE are separate, not from tethering. Therefore, some rewording is > needed here. As such the current text is not acceptable. Med: I added an explicit reference to Section 4 in the example listed in th= e text you quoted. > > cellular host will be configured with an IPv4 address and/or > ^^^^^^^ >o s/will be/MAY be. There is no guarantee that an UE would always open > two PDPs. [Med] As suggested by Teemu "and/or" was changed to "or". As such, "will be= " is accurate. > > an IPv6 prefix by the network. It MAY initiate another PDP > ^^^ > request in addition to the one already activated for a given > APN. > ^^^^ >o "PDP request" I would use different wording like "PDP-Context activation= " >o Expand APN on the first occurrence. [Med] Fixed. > > Traffic Flow Templates are employing a Packet Filter to > ^^^^^^^^^^^^^ >o "packet filter" ? > > PDP-Context and radio resources can be provided by the mobile > network for certain IP traffic. ^^^^^^ > >o s/mobile network/cellular network [Med] Fixed. > > This is a stronger form compared to what is specified in > Section 12.2 of [RFC6434]. The support of Neighbor Discovery > ^^^^^^^^^^^^ >o Section 5.2 should also be referenced here since e.g. RFC5942 is >mentioned > in there rather than in Section 12.2. [Med] Done, thanks. > > In particular, MTU communication via Router Advertisement > ^^^^ >o Expand MTU on the first occurrence. [Med] Fixed > > standard MTU setting due to inconsistencies in GTP [RFC3314] > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >o Expand GTP on the first occurrence. >o It is unclear what the "inconsistencies in GTP" are. The RFC3314 > definitely does not tell a thing about that. Also give a reference > to a proper GTP specification(s). [Med] re-used the same pointers as in RFC6459. > > REQ#8: The cellular host MUST support IPv6 Stateless Address > Autoconfiguration ([RFC4862]) apart from the exceptions noted in > [TS.23060] (3G) and [TS.23401] (LTE): ^^^^^^^^^^^ > ^^^^ ^^^^ >o What are the exceptions? If you mean the restrictions in 3GPP SLAAC > point to other documents like RFC6459 or RFC3316bis that detail those > out. >o s/3G/GPRS >o s/LTE/EPS [Med] Fixed. > > The cellular host MUST use the interface identifier sent in > ^ ^ >o s/interface identifier/Interface Identifier. For the consistency.. [Med] OK. > > PDP Context Accept message to configure its link local > ^^^^^^^^^^^^^^^^^^^^^^^^^^ >o Suddenly referencing to specific 3GPP signaling messages seems odd > here. I suggest to reword "3GPP PDP-Context setup signaling from > a GGSN/PGW to the cellular host" or something to that direction. [Med] changed to "To configure its link local address, the cellular host MU= ST use the Interface Identifier conveyed in 3GPP PDP-Context setup signalin= g received from a GGSN/PGW." > > REQ#9: The cellular host must comply with Section 7.3 of [RFC6434]. > ^^^^ >o s/must/MUST [Med] Fixed. >o Generally about the "Req#9". The motivational text following the > requirement title is not imho needed. The MUST for Section 7.3 of > RFC6434 is quite clear. [Med] No problem to remove it from my side. > > REQ#10: The cellular host must comply with Section 7.2.1 of > ^^^^ >o s/must/MUST [Med] Fixed. > > 1. PCP > ^^^^^^^ >o I assume PCO is meant here? [Med] Yes, this was a typo. > > Translator (CLAT, [I-D.ietf-v6ops-464xlat]) function which is > ^^^^^^^^^^^^^^^^^^^^^^^ >o RFC6877 yay! [Med] Done. > > application and IPv4-referals to work on an IPv6-only PDP. > ^^^^^^^^^^^^^ >o I suggest replacing PDP with "network" or "access network" or > "PDP-Context". [Med] changed to "connectivity" > > DNSSEC. Means to configure or discover a PREFIX64 is also > ^^^^^^^ ^^^^^^^ > required on the cellular device. > ^^^^^^^^ > >o Add a reference to DNSSEC. [Med] Add pointers to RFC4033, 4034 and 4035. >o Pref64 discovery is already SHOULDed in Req11. Mentioning it here > again seems unnecessary repetition. [Med] As suggested by Teemu a reference to REQ#11 was added to the text. > > The support of PCP is seen as a driver to save battery > ^^^^^^^^^^^^^^^^^^^^^^ > consumption exacerbated by keepalive messages. PCP also > >o This is a strong statement. Do we have documented proof of that? > PCP itself does not solve or even help that much the battery > savings since the host side applications still need to coordinate > among themselves and it is a different issue & problem. [Med] The text only says "is seen as a driver to save battery. This text is= basically restating what is included on the base PCP spec: " This helps re= duce bandwidth on the subscriber's access network, traffic to the server, and battery consumption on mobile devices. " > > REQ#15: When the cellular host is dual stack connected, it SHOULD > ^^^^^^^^^^^^^^^^^^^^^ >o Using what mechanisms? Two PDPs? IPv4v6 PDP or XLAT? Or should we > actually not care? Some clarification would be nice here, though. [Med] i.e., configured with an IPv4 address and IPv6 prefix. Text is update= d now. > > [I-D.ietf-mif-happy-eyeballs-extension] for MIFed devices. > ^^^^^ >o Care to expand.. [Med] Teemu suggested to remove the MIF reference...which I accepted. > > REQ#17: The cellular host SHOULD NOT perform Duplicate Address > Detection (DAD) for these Global IPv6 addresses (as the GGSN or > PDN-GW must not configure any IPv6 addresses using the prefix > allocated to the cellular host). Refer to Section 4 for DAD > considerations on the LAN interface when the 3GPP connection is > shared. > >o This is already in RFC6459 and RFC 3316(bis). No need to repeat the > requirement here again and Section 4 deals with the specific case > that is not in the previously mentioned RFCs. I suggest removing > the Req17. Med: Done. > >6) Section 2.1 - Wi-Fi Connectivity > >2.1. WiFi Connectivity > ^^^^^^^^ >o Why not adding "Requirements" here as well? [Med] Done. > > REQ#19: IPv6 MUST be supported on the Wi-Fi interface. In > particular, IPv6-only connectivity MUST be supported over the > Wi-Fi interface. > >o Suggest rewording "..Wi-Fi interface without configuring IPv4 > on the interface." > > Recent tests revealed that IPv4 configuration is required > to enable IPv6-only connectivity. Indeed, some cellular > handsets can access a Wi-Fi IPv6-only network by > configuring first a static IPv4 address. Once the device > is connected to the network and the wlan0 interface got an > IPv6 global address, the IPv4 address can be deleted from > the configuration. This avoids the device to ask > automatically for a DHCPv4 server, and allows to connect to > IPv6-only networks. > >o I would delete this and just state that "Failing to configure an > IPv4 address on the interface MUST NOT prohibit using IPv6 on the > same interface." [Med] "Recent test.." is now changed to " Some tests..". I didn't removed = that text as it provides the context. I added the explicit sentence you pro= posed. > > >7) Section 3 - Advanced Requirements > > REQ#22: The cellular host must comply with Section 5.6.1 of > ^^^^ >o s/must/MUST [Med] Fixed > > REQ#23: The cellular host must comply with Section 5.9.3 of > ^^^^ >o s/must/MUST [Med] Fixed. > > permanent interface identifier. [RFC4941] does not require > any DAD mechanism to be activated as the GGSN (or PDN-GW) > MUST NOT configure any global address based on the prefix > allocated to the cellular host. > > REQ#24: The cellular host SHOULD support ROHC for IPv6 ([RFC5795]). > >o I would say which ROHC profiles SHOULD be supported. It makes no sense > to require all, since IMHO ROHC has limited benefit in 3G/LTE. I would > strongly recommend aligning this requirement to GSMA PRD.92. Med: Profile 1 and 2 are explicitly included in the REQ now. > >o IMHO no need to repeat the DAD behaviour. I strongly suggest removing > the last sentence. > > This is a stronger form compared to what is specified in > [RFC6434]. The justification is some flags are used by the > GGSN (or PDN-GW) to inform cellular hosts about the > autoconfiguration process. > ^^^^^^^^^^^^^^^^^^^^^^^^^^ >o Care to reveal the flags that do the justification? What are told now > by GGSNs/PGWs more in extended flags? I am OK with the requirement as > such but the justification text is just confusing. I suggest removing > it. > > REQ#26: The cellular host must comply with Section 5.3 of [RFC6434] > ^^^^ >o s/must/MUST [Med] Done. > >8) Section 4 - Cellular Devices with LAN Capabilities > >4. Cellular Devices with LAN Capabilities > ^^^ >o So this is strongly about LAN, not WLAN? > > are sharing the same GPRS, UMTS or EPS connection. In addition to > ^^^^ ^^^^ ^^^ >o s/GPRS/2G >o s/UMTS/3G >o s/EPS/LTE [Med] OK, done. > > WAN and the Delegated Prefix to be aggregatable, so the > ^^^ >o Expand WAN on the first occurrence. [Med] Done. > > (e.g., halving the Delegated prefix and assigning the WAN > ^^^ >o s/Delegated/delegated [Med] Fixed. > > requirements specified in [RFC6204]. > ^^^^^^^ >o I would suggest referencing to RFC6204bis since it has some language > that takes cellular network particularly into considerations. Med: RFC6204 is sufficient. > > reduced to 1440 bytes. While a host may generate packets > ^^^^^ >o TS.23060 has specific MTU size recommendations. I would reference to > that and also "reveal" the number stated in there. [Med] Done. > >9) Section 5 - APIs & Applications > > REQ#33: Applications MUST be independent of the underlying IP > address family. > >o I think SHOULD/RECOMMENDED with some stressing would be more > appropriate. There could be cases where IP version specific > software is justified, e.g. diagnostic tools and such.. Maybe > "MUST be independent of the underlying IP address family, > unless done purposely address family specific for a specific > reasons." [Med] IMO, adding exceptions will nullify the REQ. > >10) Section 6 - Security Considerations > > The security considerations identified in [RFC3316] are to be taken > ^^^^^^^^^ >o Use RFC3316bis and also reference to RFC6459 that has some additional > security considerations to RFC3316. [Med] Ok, done. From mohamed.boucadair@orange.com Mon Apr 22 23:11:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372EB21F9660 for ; Mon, 22 Apr 2013 23:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQGpqrqgzrOX for ; Mon, 22 Apr 2013 23:11:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 49FAF21F965F for ; Mon, 22 Apr 2013 23:11:52 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id B04173B4A22; Tue, 23 Apr 2013 08:11:51 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 97B454C024; Tue, 23 Apr 2013 08:11:51 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 23 Apr 2013 08:11:51 +0200 From: To: Teemu Savolainen Date: Tue, 23 Apr 2013 08:11:50 +0200 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt Thread-Index: Ac4/6W9AWe4R44bURMK7+gtPu0oX3w== Message-ID: <94C682931C08B048B7A8645303FDC9F36EC86EB947@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EC86EB947PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.23.54234 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 06:11:58 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EC86EB947PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Teemu, Please see inline. Cheers, Med De : Teemu Savolainen [mailto:tsavo.stds@gmail.com] Envoy=E9 : lundi 22 avril 2013 11:51 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : v6ops@ietf.org Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.t= xt Hi Med, Thank you for your prompt reply, further comments inline for some points (r= est cut): Cheers, Teemu 2) In my opinion all references to 3316 should be changed to draft-ietf-v6o= ps-rfc3316bis, [Med] Will see how to update the text. and there is no need to compare RFC3316 with 3316bis draft in here (in sect= ion 1), as the 3316bis will obsolete the 3316. [Med] Are you referring to this text? [RFC3316] lists a set of features to be supported by cellular hosts to connect to 3GPP cellular networks. Since the publication of that document, new functions have been specified within the 3GPP and the IETF whilst others have been updated. Moreover, in the light of recent IPv6 production deployments, additional features to facilitate IPv6-only deployments while accessing IPv4-only service are to be considered. Are you suggesting this text is to be removed? What I'm saying is that RFC3316bis will obsolete RFC3316, hence this docume= nt should not be referring to obsolete RFC - assuming both these complete r= oughly at the same time. Hence you should replace the RFC3316 with RFC3316b= is and modify the text accordingly. I.e. describe what this document brings= in addition. Maybe something like: [RFC3316bis] lists a set of features to be supported by cellular hosts to connect to 3GPP cellular networks. In the light of recent IPv6 production deployments, additional features to facilitate IPv6-only deployments while accessing IPv4-only service are to be considered. [Med] OK with your proposed wording. or something? 3) Why some of the requirements of RFC6434 are duplicated herein with same = keywords, e.g. REQ#1 has MUST for same thing RFC6434 has MUST. I would supp= ose a profile document could say that mobile device MUST follow RFC6434, ex= cept when ? [Med] Isn't this covered by this text: Pointers to some requirements listed in [RFC6434] are included in this profile. The justification for using a stronger language compared to what is specified in [RFC6434] is provided for some requirements. If you think this is not clear, we can update the text to better clarify th= e logic. Well I just don't see why to point to some requirements in RFC6434, except = to use stronger (or weaker) language for the requirements explicitly pointe= d at. Could the document perhaps state that RFC6434 is required but with exceptio= ns and additions listed in this document? [Med] We want to call out explicitly the requirements which are of interest= and therefore have a comprehensive list of requirements. A justification t= ext is added when the normative language is stronger. 4) REQ#2 title does not include IPv4, but IPv4 PDP is mentioned in text:"in= addition to the IPv4 PDP context." Does this mean IPv4 PDP context is also= required, or is IPv4 PDP optional? Needs clarification. [Med] The title focuses only on the IPv6-related PDP contexts. I don't thin= k there is a value to use the normative language for IPv4 PDP. I was asking because the "Both IPv6 and IPv4v6 PDP contexts MUST be support= ed in addition to the IPv4 PDP." sounds like normative text. I was thinkin= g whether this document allows a device with just IPv6 and IPv4v6 PDP cont= ext support. Probably no use for such device in near future, but I was neve= rtheless wondering if IPv4 is explicitly required. [Med] I see your point. I removed "in addition to the IPv4 PDP". The text i= s silent about IPv4 PDP-Context support. 5) Is it required to be able to support different PDP types in parallel, e.= g. IPv4 in parallel with IPv4v6? That probably is (e.g. IPv4 for MMS, IPv4v= 6 for Internet), but do you wish to write it down? [Med] IMHO, this is not specific to IPv6. I don't think there is a value to= explicit this for IPv6-related PDP contexts. True, ok for me not to talk about this here. 6) REQ#3 says device MUST request IPv4v6 if the cellular host is dual-stack= . Well, this is how 3GPP writes it as well... but in reality all this depen= ds on provisioning. So you should say that this is the way, unless provisio= ned to do otherwise.. [Med] Would you be OK if the text is changed as follows: OLD: the cellular host MUST request ... NEW: the cellular host MUST request by default ... Yes, that would be fine. [Med] Done. 9) REQ#4: What about RFC6106? I would think that could be MAY/SHOULD in add= ition to MUST for PCO option support. [Med] This is discussed in REQ#9. No? True, probably by the time I hit REQ#9 I had forgotten this comment already= :) 10) REQ#6: should you clarify that MTU option really needs to be received a= nd acted upon? [Med] Can you explicit what change you want to see added to the text? MTU communication via RA from SHOULD to MUST? [Med] Agree with MUST 11) REQ#9 says in title "must" but in text "SHOULD". Which way do you inten= d? I could go for MUST in order to allow more flexibility in the future, bu= t SHOULD is ok as well [Med] "must comply" with Section 7.3 means it needs to follow what is descr= ibed in that section: i.e., SHOULD support 6106. This is indicated explicit= ly in the text. What does it mean when one "must comply" with "SHOULD"?-) If the normative = text says SHOULD, why the title could not be "The cellular host should comp= ly with.." 12) REQ#10 says in title "must", but why? What if device just does not need= anything via stateless DHCPv6? SHOULD would be better? [Med] Idem as above. And same as above, "must comply" with "SHOULD" is confusing. 14) REQ#11 do you have requirement [Med] See the justification text and also the DNSSEC case. This was a typo from me, I thought of something, checked it out, and then f= orgot to delete the text I had started writing... 16) REQ#15 refers to MIF - I would probably simply drop the MIF reference o= ut, as if MIF is included also other problems start creeping in (specific r= outes, DNS selection, provisioning domains...) - i.e. better exclude MIF pr= oblematics from this document. You could explicitly state whether you prefe= r DNS communications to use IPv4 or IPv6 in dual-stack scenarios, as that s= eems to be something currently more or less random. [Med] No problem to remove the MIF reference. For the DNS case, are you sug= gesting to add a sentence such as: "When both IPv4 and IPv6 DNS servers are configured, a dual-stack host MUST= contact first its IPv6 DNS server." Yes, that would suit me, but I wanted to check whether you wish it that way= , or if "random" is ok (or e.g. happy eyeballs style approach). [Med] I changed the text as proposed above. 17) Section 2.1 I would like clarification whether this applies to "downlin= k" WiFi, "uplink" WiFi, or both. It sounds like about uplink, but please sp= ell it out. [Med] What difference do you make between those two? Never mind, I was thinking perhaps a bit too far. It talks already about ho= tspots anyway. [Med] ;-) 19) REQ#19 I would remove the background text about "some recent tests reve= aled" on some OS - it just does not suit well for profile document living f= or a looong time. Alternatively you could have Appendix that includes some = of the real-world experiences of particular implementations? [Med] We put that text there to record the encountered issue with some impl= ementations. If the requirement is supported, this wouldn't be an issue. I = will discuss with my co-author how to handle this comment. Thanks. I'm fine with the requirement, but if you need to keep it for a while still= that's ok. [Med] Thanks. 20) REQ#22 why this is advanced requirement? I would call it basic.. and I = would like to emphasize capability to receive MTU option via RA. [Med] Would moving this REQ to be called out just after REQ#6 be OK with yo= u? Yes. [Med] Done. 21) REQ#23 - I am not convinced full RFC4941 is always required. Enough pri= vate addresses could be obtained by simpler ways as well, I believe. Hence= I would rephrase that hosts MUST have RFC4941 or other means for providing= privacy addressing. I.e. the requirement should be about privacy addresses= , not RFC4941. [Med] Makes sense. What about this change? OLD: The cellular host must comply with Section 5.9.3 of [RFC6434] for t= he support of the Privacy Extensions for Stateless Address Autoconfiguration in IPv6. The activation of privacy extension makes it more difficult to track a host over time when compared to using a permanent interface identifier. [RFC4941] does not require any DAD mechanism to be activated as the GGSN (or PDN-GW) MUST NOT configure any global address based on the prefix allocated to the cellular host. NEW: The cellular host MUST be able able to generate IPv6 addresses which prese= rve privacy. The activation of privacy extension (e.g., using [RFC4941]) makes it more difficult to track a host over time when compared to using a permanent interface identifier. Note, [RFC4941] does not require any DAD mechanism to be activated as the GGSN (or PDN-GW) MUST NOT configure any global address based on the prefix allocated to the cellular host. Would work for me. [Med] Done. Thanks. --_000_94C682931C08B048B7A8645303FDC9F36EC86EB947PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=  

Hi Med,

 = ;

Thank = you for your prompt reply, further comments inline for some points (rest cu= t):

 

Cheers,

 

Teemu

 

=

2) In my opin= ion all references to 3316 should be changed to draft-ietf-v6ops-rfc3316bis= ,

[Med] Will see how to u= pdate the text.

=  

<= span lang=3DEN-US>and there is no need to compare RFC3316 with 3316bis draf= t in here (in section 1), as the 3316bis will obsolete the 3316.=

[Med] Are you referring to this text?

 

   [RFC3316] list= s a set of features to be supported by cellular hosts

   to connect to 3GPP cellular netw= orks.  Since the publication of that

   document, new functions have been specified = within the 3GPP and the

=    IETF whilst others have been updated.  Moreover, in the l= ight of

   rec= ent IPv6 production deployments, additional features to facilitate

   IPv6-only deploymen= ts while accessing IPv4-only service are to be

   considered.

 =

Are you suggesting this text is to be re= moved?

 

What I'm = saying is that RFC3316bis will obsolete RFC3316, hence this document should= not be referring to obsolete RFC - assuming both these complete roughly at= the same time. Hence you should replace the RFC3316 with RFC3316bis and mo= dify the text accordingly. I.e. describe what this document brings in addit= ion. Maybe something like:

 

  &= nbsp;[RFC3316bis] lists a set = of features to be supported by cellular hosts

   to connect to 3GPP cellular networks. &n= bsp;In the light of

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbs= p;  recent IPv6 production deployments, additional features to facilit= ate

   IPv6-on= ly deployments while accessing IPv4-only service are to be

   considered.=

[Med] OK with your proposed wording.

or something= ? 

<= span lang=3DEN-US style=3D'color:#500050'>3) Why some of the requirements o= f RFC6434 are duplicated herein with same keywords, e.g. REQ#1 has MUST for= same thing RFC6434 has MUST. I would suppose a profile document could say = that mobile device MUST follow RFC6434, except when <exceptions> ?

[Med] Isn’t this covered by this text:

 

   Pointers to some requir=
ements listed in [RFC6434] are included in
   this profile.  The justifi=
cation for using a stronger language
   compared to what is specified in [RFC6434] is provided for some
&=
nbsp;  requirements.

If you t= hink this is not clear, we can update the text to better clarify the logic.=

Well I just don't see why = to point to some requirements in RFC6434, except to use stronger (or weaker= ) language for the requirements explicitly pointed at. 

 =

Could the doc= ument perhaps state that RFC6434 is required but with exceptions and additi= ons listed in this document?

[Med] We want to call out explicitly the requirements which are of i= nterest and therefore have a comprehensive list of requirements. A justific= ation text is added when the normative language is stronger.

 =

4) REQ#2 title does not include IPv4, but IPv4 PDP = is mentioned in text:"in addition to the IPv4 PDP context." Does = this mean IPv4 PDP context is also required, or is IPv4 PDP optional? Needs= clarification.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>[M= ed] I see your point. I removed “in addition to the IPv4 PDP”. The text = is silent about IPv4 PDP-Context support.

5) Is it required t= o be able to support different PDP types in parallel, e.g. IPv4 in parallel= with IPv4v6? That probably is (e.g. IPv4 for MMS, IPv4v6 for Internet), bu= t do you wish to write it down?

6) REQ#3 says device MUST request IPv4v6 if the cellular host i= s dual-stack. Well, this is how 3GPP writes it as well... but in reality al= l this depends on provisioning. So you should say that this is the way, unl= ess provisioned to do otherwise..

[Med] Would you be OK if the text is changed as follows:

OLD:

the cellular host MUST reques= t …

NEW:

the = cellular host MUST request by default …

Yes, that would be fine.

[Med] Done.

 

<= div>

9) REQ#4: What about RFC6106= ? I would think that could be MAY/SHOULD in addition to MUST for PCO option= support.

[Med] This is discus= sed in REQ#9. No?

True, pro= bably by the time I hit REQ#9 I had forgotten this comment already:)

 

10) REQ#6: should you clarify that MTU option really needs to b= e received and acted upon?

[Me= d] Can you explicit what change you want to see added to the text?

=

MTU communication via RA from SHOUL= D to MUST?

[Med] Agree= with MUST

 

11) REQ#9 says in ti= tle "must" but in text "SHOULD". Which way do you inten= d? I could go for MUST in order to allow more flexibility in the future, bu= t SHOULD is ok as well

[Med] &= #8220;must comply” with Section 7.3 means it needs to follow what is = described in that section: i.e., SHOULD support 6106. This is indicated exp= licitly in the text.

<= /div>

What d= oes it mean when one "must comply" with "SHOULD"?-) If = the normative text says SHOULD, why the title could not be "The cellular host should comply with.."

 

12) REQ#10 says in title "must", but why? What if de= vice just does not need anything via stateless DHCPv6? SHOULD would be bett= er?

[Med] Idem as above.

And same as above, "must co= mply" with "SHOULD" is confusing.

 

<= /div>

14) REQ#= 11 do you have requirement

[M= ed] See the justification text and also the DNSSEC case.

 

This was a typo from me, I thought of s= omething, checked it out, and then forgot to delete the text I had started = writing... 

16) REQ#15 refers to MI= F - I would probably simply drop the MIF reference out, as if MIF is includ= ed also other problems start creeping in (specific routes, DNS selection, p= rovisioning domains...) - i.e. better exclude MIF problematics from this do= cument. You could explicitly state whether you prefer DNS communications to= use IPv4 or IPv6 in dual-stack scenarios, as that seems to be something cu= rrently more or less random.

[Med] No problem to remove the MIF reference.= For the DNS case, are you suggesting to add a sentence such as:

“When both IP= v4 and IPv6 DNS servers are configured, a dual-stack host MUST contact firs= t its IPv6 DNS server.”

Yes, that would suit me, but I wanted to check whether you wish it that = way, or if "random" is ok (or e.g. happy eyeballs style approach)= .

&= nbsp;[Med] I changed the text as proposed above.

17) Section 2.1 I would like clarification= whether this applies to "downlink" WiFi, "uplink" WiFi= , or both. It sounds like about uplink, but please spell it out.=

[Med] What difference do you make betwee= n those two?

Never mind, I = was thinking perhaps a bit too far. It talks already about hotspots anyway.=

[Med] ;-)<= /span> 

19) REQ#19 I would remove the= background text about "some recent tests revealed" on some OS - = it just does not suit well for profile document living for a looong time. A= lternatively you could have Appendix that includes some of the real-world e= xperiences of particular implementations?

=

[Med] We put that text there to record the encounter= ed issue with some implementations. If the requirement is supported, this w= ouldn’t be an issue. I will discuss with my co-author how to handle t= his comment. Thanks.

<= /div>

I'm fi= ne with the requirement, but if you need to keep it for a while still that'= s ok.

 [Med] Thanks.

20) REQ#22 why this is advanced requirement? I would call it basic.. = and I would like to emphasize capability to receive MTU option via RA.=

[Med] Would moving this REQ to be = called out just after REQ#6 be OK with you?<= o:p>

Yes. 

= [Med] Done.

21) REQ#23 -= I am not convinced full RFC4941 is always required. Enough private  a= ddresses could be obtained by simpler ways as well, I believe. Hence I woul= d rephrase that hosts MUST have RFC4941 or other means for providing privac= y addressing. I.e. the requirement should be about privacy addresses, not R= FC4941.

[Med] Makes sense. Wha= t about this change?

=  OLD:

 The cellular host must comply w= ith Section 5.9.3 of

  &nb=
sp;       [RFC6434] for the support of the Privacy Extensions for
<= pre>        &nbs= p; Stateless Address Autoconfiguration in IPv6.

 

         &nbs=
p;   The activation of privacy extension makes it more difficult<=
o:p>
    &nbs=
p;        to track a host over time when=
 compared to using a
 &=
nbsp;           permanent=
 interface identifier.  [RFC4941<=
/a>] does not require
          &n=
bsp;  any DAD mechanism to be activated as the GGSN (or PDN-GW)
     &nbs=
p;       MUST NOT configure any global addres=
s based on the prefix
 =
            allocate=
d to the cellular host.

 NE= W:

 <= /span>The cellular host MUST be able able to generate IP= v6 addresses which preserve privacy.

 

            =
; The activation of privacy extension (e.g., using [RFC4941]) makes it more difficult
     =
        to track a host over time when c=
ompared to using a
 &nb=
sp;           permanent i=
nterface identifier. Note, [RFC4941] does not require
           &nb=
sp; any DAD mechanism to be activated as the GGSN (or PDN-GW)
      =
       MUST NOT configure any global address =
based on the prefix
 &n=
bsp;           allocated =
to the cellular host.
= --_000_94C682931C08B048B7A8645303FDC9F36EC86EB947PUEXCB1Bnante_-- From tsavo.stds@gmail.com Tue Apr 23 05:41:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0407421F9688 for ; Tue, 23 Apr 2013 05:41:44 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STPIuMGZPOaM for ; Tue, 23 Apr 2013 05:41:42 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 98B7421F96B3 for ; Tue, 23 Apr 2013 05:41:39 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hm14so2819368wib.11 for ; Tue, 23 Apr 2013 05:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OWS0ngqPaFZwfOJeSJFWIqs89VFJasZEwoVuzU8th0U=; b=Jh28zMts7SkMq8DrkFX9kBkN6k+gk5MZkCgHSOYCy4o43CHwvLzkUr/NJjsD40+Mc3 +8/5bCRkwZxcFDknCgS1QyFYwSpveWTedtPb2c9o1MbAUKkSwXStapJX+1G5fYNj214Q 2/qTXdKNil2bAnvAo7hHhpST0QqtfjYrg5MOvBGk/Wdf9wYqk4b32FF5Yfct66YrJzYm MtVf6ds2T/ensE1+ujIAekm9a5xxZCiRBI34LSo9OSq8dcUeqDNRIt11YHpt9jvPXO5N 8LwokMVMwxtb7YbIrGB3hysU58rZr4dP2Iy3jfV5HmDTYv/cqy7IGXedKUGHVaZO0kPQ keKg== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr60739476wjc.35.1366720898534; Tue, 23 Apr 2013 05:41:38 -0700 (PDT) Received: by 10.194.152.71 with HTTP; Tue, 23 Apr 2013 05:41:14 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC86EB947@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EC86EB947@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 23 Apr 2013 15:41:14 +0300 Message-ID: From: Teemu Savolainen To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=089e013d1da8aa127904db0681c5 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 12:41:44 -0000 --089e013d1da8aa127904db0681c5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It seems all my comments are now addressed - I'll give a reread for the next revision and try to see if I can come up with further comments. Thank you, Teemu 2013/4/23 > Hi Teemu,**** > > ** ** > > Please see inline.**** > > Cheers,**** > > Med**** > > ** ** > > *De :* Teemu Savolainen [mailto:tsavo.stds@gmail.com] > *Envoy=E9 :* lundi 22 avril 2013 11:51 > > *=C0 :* BOUCADAIR Mohamed OLNC/OLN > *Cc :* v6ops@ietf.org > *Objet :* Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-device-profile-01.txt**** > > ** ** > > Hi Med,**** > > ** ** > > Thank you for your prompt reply, further comments inline for some points > (rest cut):**** > > ** ** > > Cheers,**** > > ** ** > > Teemu**** > > ** ** > > 2) In my opinion all references to 3316 should be changed to > draft-ietf-v6ops-rfc3316bis,**** > > [Med] Will see how to update the text.**** > > **** > > and there is no need to compare RFC3316 with 3316bis draft in here (in > section 1), as the 3316bis will obsolete the 3316.**** > > [Med] Are you referring to this text?**** > > **** > > [RFC3316] lists a set of features to be supported by cellular hosts***= * > > to connect to 3GPP cellular networks. Since the publication of that**= * > * > > document, new functions have been specified within the 3GPP and the***= * > > IETF whilst others have been updated. Moreover, in the light of**** > > recent IPv6 production deployments, additional features to facilitate*= * > ** > > IPv6-only deployments while accessing IPv4-only service are to be**** > > considered.**** > > **** > > Are you suggesting this text is to be removed? **** > > ** ** > > What I'm saying is that RFC3316bis will obsolete RFC3316, hence this > document should not be referring to obsolete RFC - assuming both these > complete roughly at the same time. Hence you should replace the RFC3316 > with RFC3316bis and modify the text accordingly. I.e. describe what this > document brings in addition. Maybe something like:**** > > ** ** > > [RFC3316bis] lists a set of features to be supported by cellular hosts= * > *** > > to connect to 3GPP cellular networks. In the light of**** > > recent IPv6 production deployments, additional features to facilitate*= * > ** > > IPv6-only deployments while accessing IPv4-only service are to be**** > > considered.**** > > [Med] OK with your proposed wording.**** > > or something? **** > > 3) Why some of the requirements of RFC6434 are duplicated herein with sam= e > keywords, e.g. REQ#1 has MUST for same thing RFC6434 has MUST. I would > suppose a profile document could say that mobile device MUST follow > RFC6434, except when ?**** > > [Med] Isn=92t this covered by this text:**** > > **** > > Pointers to some requirements listed in [RFC6434 ] are included in**** > > this profile. The justification for using a stronger language**** > > compared to what is specified in [RFC6434 ] is provided for some**** > > requirements.**** > > If you think this is not clear, we can update the text to better clarify > the logic.**** > > Well I just don't see why to point to some requirements in RFC6434, excep= t > to use stronger (or weaker) language for the requirements explicitly > pointed at. **** > > ** ** > > Could the document perhaps state that RFC6434 is required but with > exceptions and additions listed in this document?**** > > [Med] We want to call out explicitly the requirements which are of > interest and therefore have a comprehensive list of requirements. A > justification text is added when the normative language is stronger.**** > > **** > > 4) REQ#2 title does not include IPv4, but IPv4 PDP is mentioned in > text:"in addition to the IPv4 PDP context." Does this mean IPv4 PDP conte= xt > is also required, or is IPv4 PDP optional? Needs clarification.**** > > [Med] The title focuses only on the IPv6-related PDP contexts. I don=92t > think there is a value to use the normative language for IPv4 PDP.**** > > I was asking because the "Both IPv6 and IPv4v6 PDP contexts MUST be > supported in addition to the IPv4 PDP." sounds like normative text. I > was thinking whether this document allows a device with just IPv6 and > IPv4v6 PDP context support. Probably no use for such device in near futur= e, > but I was nevertheless wondering if IPv4 is explicitly required.**** > > [Med] I see your point. I removed =93in addition to the IPv4 PDP=94. The = text > is silent about IPv4 PDP-Context support.**** > > 5) Is it required to be able to support different PDP types in parallel, > e.g. IPv4 in parallel with IPv4v6? That probably is (e.g. IPv4 for MMS, > IPv4v6 for Internet), but do you wish to write it down?**** > > [Med] IMHO, this is not specific to IPv6. I don=92t think there is a valu= e > to explicit this for IPv6-related PDP contexts.**** > > True, ok for me not to talk about this here. **** > > 6) REQ#3 says device MUST request IPv4v6 if the cellular host is > dual-stack. Well, this is how 3GPP writes it as well... but in reality al= l > this depends on provisioning. So you should say that this is the way, > unless provisioned to do otherwise..**** > > [Med] Would you be OK if the text is changed as follows:**** > > OLD:**** > > the cellular host MUST request =85**** > > NEW:**** > > the cellular host MUST request by default =85**** > > Yes, that would be fine.**** > > [Med] Done. **** > > **** > > 9) REQ#4: What about RFC6106? I would think that could be MAY/SHOULD in > addition to MUST for PCO option support.**** > > [Med] This is discussed in REQ#9. No?**** > > True, probably by the time I hit REQ#9 I had forgotten this comment > already:)**** > > **** > > 10) REQ#6: should you clarify that MTU option really needs to be received > and acted upon?**** > > [Med] Can you explicit what change you want to see added to the text?**** > > MTU communication via RA from SHOULD to MUST?**** > > [Med] Agree with MUST**** > > **** > > 11) REQ#9 says in title "must" but in text "SHOULD". Which way do you > intend? I could go for MUST in order to allow more flexibility in the > future, but SHOULD is ok as well**** > > [Med] =93must comply=94 with Section 7.3 means it needs to follow what is > described in that section: i.e., SHOULD support 6106. This is indicated > explicitly in the text.**** > > What does it mean when one "must comply" with "SHOULD"?-) If the normativ= e > text says SHOULD, why the title could not be "The cellular host should > comply with.."**** > > **** > > 12) REQ#10 says in title "must", but why? What if device just does not > need anything via stateless DHCPv6? SHOULD would be better?**** > > [Med] Idem as above.**** > > And same as above, "must comply" with "SHOULD" is confusing.**** > > **** > > 14) REQ#11 do you have requirement **** > > [Med] See the justification text and also the DNSSEC case.**** > > ** ** > > This was a typo from me, I thought of something, checked it out, and then > forgot to delete the text I had started writing... **** > > 16) REQ#15 refers to MIF - I would probably simply drop the MIF reference > out, as if MIF is included also other problems start creeping in (specifi= c > routes, DNS selection, provisioning domains...) - i.e. better exclude MIF > problematics from this document. You could explicitly state whether you > prefer DNS communications to use IPv4 or IPv6 in dual-stack scenarios, as > that seems to be something currently more or less random.**** > > [Med] No problem to remove the MIF reference. For the DNS case, are you > suggesting to add a sentence such as: **** > > =93When both IPv4 and IPv6 DNS servers are configured, a dual-stack host > MUST contact first its IPv6 DNS server.=94**** > > Yes, that would suit me, but I wanted to check whether you wish it that > way, or if "random" is ok (or e.g. happy eyeballs style approach).**** > > [Med] I changed the text as proposed above.**** > > 17) Section 2.1 I would like clarification whether this applies to > "downlink" WiFi, "uplink" WiFi, or both. It sounds like about uplink, but > please spell it out.**** > > [Med] What difference do you make between those two?**** > > Never mind, I was thinking perhaps a bit too far. It talks already about > hotspots anyway.**** > > [Med] ;-) **** > > 19) REQ#19 I would remove the background text about "some recent tests > revealed" on some OS - it just does not suit well for profile document > living for a looong time. Alternatively you could have Appendix that > includes some of the real-world experiences of particular implementations= ? > **** > > [Med] We put that text there to record the encountered issue with some > implementations. If the requirement is supported, this wouldn=92t be an > issue. I will discuss with my co-author how to handle this comment. Thank= s. > **** > > I'm fine with the requirement, but if you need to keep it for a while > still that's ok.**** > > [Med] Thanks.**** > > 20) REQ#22 why this is advanced requirement? I would call it basic.. and = I > would like to emphasize capability to receive MTU option via RA.**** > > [Med] Would moving this REQ to be called out just after REQ#6 be OK with > you?**** > > Yes. **** > > [Med] Done.**** > > 21) REQ#23 - I am not convinced full RFC4941 is always required. Enough > private addresses could be obtained by simpler ways as well, I believe. > Hence I would rephrase that hosts MUST have RFC4941 or other means for > providing privacy addressing. I.e. the requirement should be about privac= y > addresses, not RFC4941.**** > > [Med] Makes sense. What about this change?**** > > OLD:**** > > The cellular host must comply with Section 5.9.3 of > **** > > [RFC6434] fo= r the support of the Privacy Extensions for**** > > Stateless Address Autoconfiguration in IPv6.**** > > **** > > The activation of privacy extension makes it more difficult*= *** > > to track a host over time when compared to using a**** > > permanent interface identifier. [RFC4941 ] does not require**** > > any DAD mechanism to be activated as the GGSN (or PDN-GW)***= * > > MUST NOT configure any global address based on the prefix***= * > > allocated to the cellular host.**** > > NEW:**** > > The cellular host MUST be able able to generate IPv6 addresses which > preserve privacy.**** > > **** > > The activation of privacy extension (e.g., using [RFC4941 ]) makes it more difficult**** > > to track a host over time when compared to using a**** > > permanent interface identifier. Note, [RFC4941 ] does not require**** > > any DAD mechanism to be activated as the GGSN (or PDN-GW)***= * > > MUST NOT configure any global address based on the prefix***= * > > allocated to the cellular host.**** > > ** ** > > Would work for me. **** > > [Med] Done. Thanks.**** > --089e013d1da8aa127904db0681c5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
It seems all my comments are now addressed - I'll give= a reread for the next revision and try to see if I can come up with furthe= r comments.

Thank you,

Teemu


2013/4/= 23 <mohamed.boucadair@orange.com>

Hi Teemu,

=A0

<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Courier New= ";color:#1f497d">Please see inline.

Cheers,

Med

=A0

De=A0: Teemu S= avolainen [mailto:tsavo.stds@gmail.com]
Envoy=E9=A0: lundi 22 avril 2013 11:51

<= br>=C0=A0: BOUCADAIR Mohamed OLNC/OLN
Cc=A0: v6ops@ietf.org
Objet=A0: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt=

=A0

Hi Med,

=A0<= /u>

Thank you for your p= rompt reply, further comments inline for some points (rest cut):<= /u>

=A0

Cheers,

= =A0

Teemu

=A0

2) In my = opinion all references to 3316 should be changed to draft-ietf-v6ops-rfc331= 6bis,

[Med] Will see how= to update the text.

=A0=

and there is no need to com= pare RFC3316 with 3316bis draft in here (in section 1), as the 3316bis will= obsolete the 3316.

[Med] Are you referring= to this text?

=A0=

=A0=A0 [RFC3316] lists a set of feature= s to be supported by cellular hosts

=A0=A0 to connect to 3GPP cellular networks= .=A0 Since the publication of that

=A0=A0 document, new functions have been sp= ecified within the 3GPP and the

=A0=A0 IETF whilst others have been updated= .=A0 Moreover, in the light of

=A0=A0 recent IPv6 production deployments, additional features to = facilitate

=A0=A0 IPv6-only deployments while accessing IPv4-only service are= to be

=A0=A0 considered.

=A0

Ar= e you suggesting this text is to be removed?

=A0

What I'm saying is that RFC3316bis will obsolete RFC= 3316, hence this document should not be referring to obsolete RFC - assumin= g both these complete roughly at the same time. Hence you should replace th= e RFC3316 with RFC3316bis and modify the text accordingly. I.e. describe wh= at this document brings in addition. Maybe something like:

=A0

= =A0 =A0[RFC3316bi= s] lists a set of features to be supported by cellular hosts

=A0=A0 to connect to 3GPP cellular networks= . =A0In the light of

=A0=A0 recent IPv6 production deployments, additional features to = facilitate

=A0=A0 IPv6-only deployments while accessing IPv4-only service are= to be

=A0=A0=A0considered.

[Med] OK with your prop= osed wording.

or something?=A0

3) Why some of the requirements of RFC6434 are duplicated herein = with same keywords, e.g. REQ#1 has MUST for same thing RFC6434 has MUST. I = would suppose a profile document could say that mobile device MUST follow R= FC6434, except when <exceptions> ?=

[Med] Isn=92t this= covered by this text:

=

=A0= 

=A0=A0 Pointers to some requirements listed i=
n [RFC6434] are included in
=A0=A0 this profile.=A0 The justification for usi=
ng a stronger language
=
=A0=A0 compared to what is specified in [RFC6434] is pr=
ovided for some
=A0=A0 requirements.
If you think this is not clear,= we can update the text to better clarify the logic.

Well I just don't see why to point to some requirements in RFC6434= , except to use stronger (or weaker) language for the requirements explicit= ly pointed at.=A0

=A0

Could the document perhaps state that RFC6434 is required but w= ith exceptions and additions listed in this document?<= /p>

[Med] We want to call o= ut explicitly the requirements which are of interest and therefore have a c= omprehensive list of requirements. A justification text is added when the n= ormative language is stronger.

= =A0

4) REQ#2 title does not include IPv4, but IPv4 PDP is mentioned i= n text:"in addition to the IPv4 PDP context." Does this mean IPv4= PDP context is also required, or is IPv4 PDP optional? Needs clarification= .

[Med] The title fo= cuses only on the IPv6-related PDP contexts. I don=92t think there is a val= ue to use the normative language for IPv4 PDP.<= u>

I was asking because the "Bot= h IPv6 and IPv4v6 PDP=A0contexts MUST be supported in addition to the IPv4 = PDP." sounds like normative text. =A0I was thinking whether =A0= this document allows a device with just IPv6 and IPv4v6 PDP context support= . Probably no use for such device in near future, but I was nevertheless wo= ndering if IPv4 is explicitly required.

[Med] I see your point.= I removed =93in addition to the IPv4 PDP= =94. The text is silent about IPv4 PDP-Contex= t support.

5) Is it required to = be able to support different PDP types in parallel, e.g. IPv4 in parallel w= ith IPv4v6? That probably is (e.g. IPv4 for MMS, IPv4v6 for Internet), but = do you wish to write it down?

[Med] IMHO, this is not= specific to IPv6. I don=92t think there is a value to explicit this for IP= v6-related PDP contexts.

True, ok for me not to talk about this here.=A0

6) REQ#3 says = device MUST request IPv4v6 if the cellular host is dual-stack. Well, this i= s how 3GPP writes it as well... but in reality all this depends on provisio= ning. So you should say that this is the way, unless provisioned to do othe= rwise..

[Med] Would you be OK i= f the text is changed as follows:=

OLD:

t= he cellular host MUST request =85=

NEW:

t= he cellular host MUST request by default =85=

Yes, that would be fine.

[Med] Done. =

= =A0

9) REQ#4:= What about RFC6106? I would think that could be MAY/SHOULD in addition to = MUST for PCO option support.

[Med] This is discussed= in REQ#9. No?

True, p= robably by the time I hit REQ#9 I had forgotten this comment already:)

= =A0

10) REQ#6: should you= clarify that MTU option really needs to be received and acted upon?=

[Me= d] Can you explicit what change you want to see added to the text?

MTU communication via RA from SHOULD to MUST?<= u>

[Med] Agree with MUST

= =A0

11) REQ#9= says in title "must" but in text "SHOULD". Which way d= o you intend? I could go for MUST in order to allow more flexibility in the= future, but SHOULD is ok as well

[Med] =93must comply=94= with Section 7.3 means it needs to follow what is described in that sectio= n: i.e., SHOULD support 6106. This is indicated explicitly in the text.

What does it mean when one "must comply" with "SHOULD&q= uot;?-) If the normative text says SHOULD, why the title could not be "= ;The cellular host should comply with.."

=A0

12) REQ#1= 0 says in title "must", but why? What if device just does not nee= d anything via stateless DHCPv6? SHOULD would be better?

[Med] Idem as above.

And same as above, "m= ust comply" with "SHOULD" is confusing.=

=A0

14) REQ#11 do you hav= e requirement

[Med] See the justification text and also the DNSSEC case.<= /span>

=A0

This was a typo from me, I thought of something, checked it ou= t, and then forgot to delete the text I had started writing...=A0=

16= ) REQ#15 refers to MIF - I would probably simply drop the MIF reference out= , as if MIF is included also other problems start creeping in (specific rou= tes, DNS selection, provisioning domains...) - i.e. better exclude MIF prob= lematics from this document. You could explicitly state whether you prefer = DNS communications to use IPv4 or IPv6 in dual-stack scenarios, as that see= ms to be something currently more or less random.

[Med] No problem t= o remove the MIF reference. For the DNS case, are you suggesting to add a s= entence such as:

=93When both IPv4 and IPv6 DN= S servers are configured, a dual-stack host MUST contact first its IPv6 DNS= server.=94

Yes, that would suit me, but I wanted to check whether you wish it tha= t way, or if "random" is ok (or e.g. happy eyeballs style approac= h).

=A0[Med] I changed the text as proposed above.

17) Section 2.1 I wou= ld like clarification whether this applies to "downlink" WiFi, &q= uot;uplink" WiFi, or both. It sounds like about uplink, but please spe= ll it out.

[Med] What difference d= o you make between those two?

Never mind, I was thinking perhaps a bit too far. It talks already abo= ut hotspots anyway.

[Med] ;-)=A0

19) REQ#1= 9 I would remove the background text about "some recent tests revealed= " on some OS - it just does not suit well for profile document living = for a looong time. Alternatively you could have Appendix that includes some= of the real-world experiences of particular implementations?=

[Med] We put= that text there to record the encountered issue with some implementations.= If the requirement is supported, this wouldn=92t be an issue. I will discu= ss with my co-author how to handle this comment. Thanks.

I'm fine with the requirement, but if you need to keep it for a wh= ile still that's ok.

=A0[Med] Thanks.<= span lang=3D"EN-US">

20) REQ#2= 2 why this is advanced requirement? I would call it basic.. and I would lik= e to emphasize capability to receive MTU option via RA.

[Med] Would moving this= REQ to be called out just after REQ#6=A0be OK with you?

Yes.=A0

[Med] Done.<= /p>

21) REQ#23 - I am not= convinced full RFC4941 is always required. Enough private =A0addresses cou= ld be obtained by simpler ways as well, I believe. Hence I would rephrase t= hat hosts MUST have RFC4941 or other means for providing privacy addressing= . I.e. the requirement should be about privacy addresses, not RFC4941.

[Med] Makes sense. What= about this change?

=A0OLD:

=A0The cellular host must comply with Section=A05.9.3 of<= /p> 

=A0=A0=A0=A0=A0=A0=A0=A0=A0 [RFC6434]<=
/a> for the support of the Privacy Extensions for
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Stateless Address Aut=
oconfiguration in IPv6.

=A0 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The activati=
on of privacy extension makes it more difficult
<= pre>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to track a ho= st over time when compared to using a 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 permanent in=
terface identifier.=A0 [RFC4941<=
span lang=3D"EN-US">] does not require
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 any DAD mech=
anism to be activated as the GGSN (or PDN-GW)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MUST NOT config= ure any global address based on the prefix 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 allocated to=
 the cellular host.

=A0NEW:

=A0The cellular host MUST be able able to generate IPv6 addresses which pres= erve privacy.

=A0

=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 The activation of privacy extension (e.g., using [RFC4941]) makes it m=
ore difficult
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to track a h=
ost over time when compared to using a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 permanent interface id=
entifier. Note, [RFC4941] does not require
=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0any DAD mech=
anism to be activated as the GGSN (or PDN-GW)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MUST NOT config= ure any global address based on the prefix 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 allocated to=
 the cellular host.

=A0=

Would work for me.=A0

[Med] Done. Thanks.


--089e013d1da8aa127904db0681c5-- From ietfc@btconnect.com Tue Apr 23 10:09:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FF721F8B2B for ; Tue, 23 Apr 2013 10:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUQT9YdnKlPG for ; Tue, 23 Apr 2013 10:09:36 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 99C7C21F8AE8 for ; Tue, 23 Apr 2013 10:09:36 -0700 (PDT) Received: from mail41-co9-R.bigfish.com (10.236.132.246) by CO9EHSOBE026.bigfish.com (10.236.130.89) with Microsoft SMTP Server id 14.1.225.23; Tue, 23 Apr 2013 17:09:35 +0000 Received: from mail41-co9 (localhost [127.0.0.1]) by mail41-co9-R.bigfish.com (Postfix) with ESMTP id D9A6C2400CC; Tue, 23 Apr 2013 17:09:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -73 X-BigFish: PS-73(zz9371Ic89bh542I1432I1418I1a09J15caKJ1447Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz8275bh8275dh1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah304l1155h) Received: from mail41-co9 (localhost.localdomain [127.0.0.1]) by mail41-co9 (MessageSwitch) id 1366736973661694_23892; Tue, 23 Apr 2013 17:09:33 +0000 (UTC) Received: from CO9EHSMHS031.bigfish.com (unknown [10.236.132.244]) by mail41-co9.bigfish.com (Postfix) with ESMTP id 95499D00056; Tue, 23 Apr 2013 17:09:33 +0000 (UTC) Received: from AMSPRD0711HT003.eurprd07.prod.outlook.com (157.56.250.181) by CO9EHSMHS031.bigfish.com (10.236.130.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 23 Apr 2013 17:09:27 +0000 Received: from DBXPRD0411HT001.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.242.14.164) with Microsoft SMTP Server (TLS) id 14.16.293.5; Tue, 23 Apr 2013 17:09:19 +0000 Message-ID: <002901ce4044$9c739f60$4001a8c0@gateway.2wire.net> From: t.petch To: , References: <94C682931C08B048B7A8645303FDC9F36EC86EB942@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 23 Apr 2013 18:04:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.165] X-FOPE-CRA-SourceIpAddress: 157.56.250.181 X-FOPE-CRA-DRYRUN: 1207119;1 X-FOPE-BFA-SENDER: ietfc@btconnect.com X-FOPE-BFA-RECEIVER: draft-ietf-v6ops-mobile-device-profile@tools.ietf.org X-FOPE-BFA-RECEIVER: v6ops@ietf.org X-FOPE-BFA-RECEIVER: mohamed.boucadair@orange.com Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: draft-ietf-v6ops-mobile-device-profile@tools.ietf.org Subject: Re: [v6ops] Review of draft-ietf-v6ops-mobile-device-profile-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 17:09:37 -0000 That's a lot of work and a lot of changes, which makes me think I have missed the boat but .... 'Cellular' has always been to me one of those quaint Americanisms that the rest of us have to put up with because America is, well, America:-( Indeed, even Wikipedia, which I would regard as the epitome of American, goes so far as to reroute 'cellular phone' to 'mobile phone also known as cellular' so mobile must be understood by some Americans! So why go for cellular rather than mobile? And I see a mix of cellular host and cellular device - are they different? (I note that in the rfc-index, usage of 'mobile' vastly outweighs that of 'cellular'). At the very least, I think that s1.2 should be expanded to give a brief summary of what you mean, what makes a 'cellular host' cellular and (if not consistent with RFC1122), a host, ditto mobile network, etc etc Tom Petch ----- Original Message ----- From: To: "Jouni Korhonen" ; Cc: Sent: Tuesday, April 23, 2013 7:08 AM Hi Jouni, Many thanks for the review. My answers inline. Cheers, Med >-----Message d'origine----- >De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] >Envoy=E9 : vendredi 19 avril 2013 10:08 >=C0 : v6ops@ietf.org Operations; draft-ietf-v6ops-mobile-device- >profile@tools.ietf.org >Objet : Review of draft-ietf-v6ops-mobile-device-profile-01 > >Hi, > >I did a review of draft-ietf-v6ops-mobile-device-profile-01. Below are >my comments. They are rather long, sorry about that ;) > >- JOuni > >--------------------------------------------------------------------- > >1) General notes > >o The I-D mixes (throughout) PDP context, PDP Context, PDP-Context. > suggest to use PDP-Context. (I have not noted any of those in > the comments below) [Med] Fixed. >o The I-D mixes (throughout) dual-stack and dual stack. Suggest > to choose one style; like dual-stack. (I have not noted any of [Med] Fixed. > those in the comments below) >o The I-D uses both RFC3316 and draft-ietf-v6ops-rfc3316bis. Suggest > to use only the latter one. [Med] The text will be tweaked. >o The I-D uses a "mobile device" in places where it should really say > a "cellular device". Use consistent wording. [Med] Will check the text. >o The I-D uses a "mobile network" where it should really use "cellular > network". In places where the network can be cellular or some other > wireless technology, I would use "wireless network" as a generic > term. [Med] The text twill be checked. >o The use of GGSN and PDN-GW should have more consistency. For example > using GGSN/PGW throughout.. [Med] OK. > >2) Abstract > > This document specifies an IPv6 profile for mobile devices. It lists > ^^^^^^^^^^^^^^ > the set of features a mobile device is to be compliant with to > ^^^^^^^^^^^^^ [Med] changed to "This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network)." From joelja@bogus.com Tue Apr 23 10:48:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3222A21F966B for ; Tue, 23 Apr 2013 10:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUKJso1bQq5w for ; Tue, 23 Apr 2013 10:48:00 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFEE21F964D for ; Tue, 23 Apr 2013 10:48:00 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r3NHlsqm072421 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 23 Apr 2013 17:47:55 GMT (envelope-from joelja@bogus.com) Message-ID: <5176C945.9040203@bogus.com> Date: Tue, 23 Apr 2013 10:47:49 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: "t.petch" , mohamed.boucadair@orange.com, v6ops@ietf.org References: <94C682931C08B048B7A8645303FDC9F36EC86EB942@PUEXCB1B.nanterre.francetelecom.fr> <002901ce4044$9c739f60$4001a8c0@gateway.2wire.net> In-Reply-To: <002901ce4044$9c739f60$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 23 Apr 2013 17:47:55 +0000 (UTC) Cc: draft-ietf-v6ops-mobile-device-profile@tools.ietf.org Subject: Re: [v6ops] Review of draft-ietf-v6ops-mobile-device-profile-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 17:48:01 -0000 On 4/23/13 10:04 AM, t.petch wrote: > That's a lot of work and a lot of changes, which makes me think I have > missed the boat but .... > > 'Cellular' has always been to me one of those quaint Americanisms that > the rest of us have to put up with because America is, well, > America:-( Indeed, even Wikipedia, which I would regard as the epitome > of American, goes so far as to reroute 'cellular phone' to 'mobile phone > also known as cellular' so mobile must be understood by some Americans! Cellular e.g. the 70s, at the time distinguished between VHF radio phone systems, and more geographically limited (e.g. cellular) services serviced by more than one transceiver... Parts of the united states have had radio mobile phone service since 1946. > > So why go for cellular rather than mobile? And I see a mix of cellular > host and cellular device - are they different? (I note that in the > rfc-index, usage of 'mobile' vastly outweighs that of 'cellular'). > > At the very least, I think that s1.2 should be expanded to give a brief > summary of what you mean, what makes a 'cellular host' cellular and (if > not consistent with RFC1122), a host, ditto mobile network, etc etc > > Tom Petch > > ----- Original Message ----- > From: > To: "Jouni Korhonen" ; > Cc: > Sent: Tuesday, April 23, 2013 7:08 AM > > Hi Jouni, > > Many thanks for the review. > > My answers inline. > Cheers, > Med > > >> -----Message d'origine----- >> De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] >> Envoyé : vendredi 19 avril 2013 10:08 >> À : v6ops@ietf.org Operations; draft-ietf-v6ops-mobile-device- >> profile@tools.ietf.org >> Objet : Review of draft-ietf-v6ops-mobile-device-profile-01 >> >> Hi, >> >> I did a review of draft-ietf-v6ops-mobile-device-profile-01. Below are >> my comments. They are rather long, sorry about that ;) >> >> - JOuni >> >> --------------------------------------------------------------------- >> >> 1) General notes >> >> o The I-D mixes (throughout) PDP context, PDP Context, PDP-Context. >> suggest to use PDP-Context. (I have not noted any of those in >> the comments below) > [Med] Fixed. > >> o The I-D mixes (throughout) dual-stack and dual stack. Suggest >> to choose one style; like dual-stack. (I have not noted any of > [Med] Fixed. > >> those in the comments below) >> o The I-D uses both RFC3316 and draft-ietf-v6ops-rfc3316bis. Suggest >> to use only the latter one. > [Med] The text will be tweaked. > >> o The I-D uses a "mobile device" in places where it should really say >> a "cellular device". Use consistent wording. > [Med] Will check the text. > >> o The I-D uses a "mobile network" where it should really use "cellular >> network". In places where the network can be cellular or some other >> wireless technology, I would use "wireless network" as a generic >> term. > [Med] The text twill be checked. > >> o The use of GGSN and PDN-GW should have more consistency. For example >> using GGSN/PGW throughout.. > [Med] OK. > >> 2) Abstract >> >> This document specifies an IPv6 profile for mobile devices. It lists >> ^^^^^^^^^^^^^^ >> the set of features a mobile device is to be compliant with to >> ^^^^^^^^^^^^^ > [Med] changed to "This document specifies an IPv6 profile for 3GPP > mobile devices. It lists the set of features a 3GPP mobile device is to > be compliant with to connect to an IPv6-only or dual-stack wireless > network (including 3GPP cellular network and IEEE 802.11 network)." > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From dougb@dougbarton.us Tue Apr 23 11:15:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C6621F955E for ; Tue, 23 Apr 2013 11:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHoE9I51iPH4 for ; Tue, 23 Apr 2013 11:15:32 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 015BE21F9588 for ; Tue, 23 Apr 2013 11:15:32 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:21a4:b7da:b032:a53a] (unknown [IPv6:2001:470:d:5e7:21a4:b7da:b032:a53a]) by dougbarton.us (Postfix) with ESMTPSA id 7F2C422B78 for ; Tue, 23 Apr 2013 18:15:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366740931; bh=C1Acu/bUquktzdO6NIzkA94+s+R5iHbRQEqDE7/e/Xo=; h=Date:From:To:Subject:References:In-Reply-To; b=dERn27BkbbBqwNvonlXyTKRlmVATqzoUXgqnDor0DL7IKpnirySl1q9HUva2uMSBs B5G9A6yjCLIShlQflo2xJRXfbVSjjJP0IV4t2o7S5RhpiXljftxM3iKfmqDkL0h9Io BzmqI1Wuo4Z3azYYtQnVHXzeJKVaoDHcV746qajg= Message-ID: <5176CFC3.30502@dougbarton.us> Date: Tue, 23 Apr 2013 11:15:31 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: v6ops@ietf.org References: <94C682931C08B048B7A8645303FDC9F36EC86EB942@PUEXCB1B.nanterre.francetelecom.fr> <002901ce4044$9c739f60$4001a8c0@gateway.2wire.net> In-Reply-To: <002901ce4044$9c739f60$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Review of draft-ietf-v6ops-mobile-device-profile-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 18:15:32 -0000 On 04/23/2013 10:04 AM, t.petch wrote: > 'Cellular' has always been to me one of those quaint Americanisms that > the rest of us have to put up with because America is, well, > America:-( One could just as easily apply the reverse logic, where us Americans have to put up with the fact that Europeans[1] make gratuitous changes to simple terms just so that they can avoid having to use the same words Americans use to refer to the same things.[2] Neither perspective is totally accurate, but consider this an FYI that your gratuitously anti-American perspective is at least as grating to me as you seem to find our use of language. My point being that rather than concentrating on how annoying Americans are, it would be infinitely more useful to phrase your proposal as, "The term 'mobile' is used much more commonly than the term 'cellular,' perhaps the draft should reflect that usage," which is a perspective I think even us annoying 'murricans would agree with. Doug [1] I am fully aware that most British don't consider themselves "European" [2] Add bonus points for all such things actually invented in America From tsavo.stds@gmail.com Tue Apr 23 11:33:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B04E21F972A for ; Tue, 23 Apr 2013 11:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.166 X-Spam-Level: X-Spam-Status: No, score=-1.166 tagged_above=-999 required=5 tests=[AWL=-1.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPjRxMWBI6z6 for ; Tue, 23 Apr 2013 11:33:20 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8A321F9725 for ; Tue, 23 Apr 2013 11:33:20 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id l13so6916324wie.1 for ; Tue, 23 Apr 2013 11:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=l6ApLNQPZ09NluB8AaHvBz/VTeufztjUkCaW3PEl3rU=; b=b/lRGs0u4E9GYlIFvaZnTFSlBfmDlgRk3UrMxg34GnoYKJThNPSDN/T81pbC80gkMV cK5jKtp1ILOEpbJMNXvB/ggtLbu7/S4Wz7R0HuHxG7otlllolpGJDxbBRJkpnAXr+TO0 kB+Hfe6VABbq0OI8FI6R/SjIrijc8a94VEE/tsegiua1mDa5nivByFMZk2lcxcguumKi J8WhwU1W0y+EUMcAVq66zgG/zCbfVuXrHzmkI12w5hz7h1WAqce0y+O2/DYHJd6X0hSx dZfBYDkSvuojWMEGPC61l6Qvk/Gua8p6VUVYyxVJnWUnPApZqzz0vyPCreQkTKBxbCm5 icww== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr63154473wjc.35.1366741999639; Tue, 23 Apr 2013 11:33:19 -0700 (PDT) Received: by 10.194.152.71 with HTTP; Tue, 23 Apr 2013 11:33:19 -0700 (PDT) Received: by 10.194.152.71 with HTTP; Tue, 23 Apr 2013 11:33:19 -0700 (PDT) In-Reply-To: <5176CFC3.30502@dougbarton.us> References: <94C682931C08B048B7A8645303FDC9F36EC86EB942@PUEXCB1B.nanterre.francetelecom.fr> <002901ce4044$9c739f60$4001a8c0@gateway.2wire.net> <5176CFC3.30502@dougbarton.us> Date: Tue, 23 Apr 2013 21:33:19 +0300 Message-ID: From: Teemu Savolainen To: Doug Barton Content-Type: multipart/alternative; boundary=089e013d1da86361c504db0b6b12 Cc: v6ops@ietf.org Subject: Re: [v6ops] Review of draft-ietf-v6ops-mobile-device-profile-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 18:33:21 -0000 --089e013d1da86361c504db0b6b12 Content-Type: text/plain; charset=ISO-8859-1 My comment against simple term of "mobile" stems from the idea that many kinds of devices can be mobile in sense of moving, but also in the sense of using some mobile technology (3GPP, 3GPP2, WiMAX...) . This document applies only to mobiles in the 3GPP domain and hence that should be stated clearly out (e.g. saying "3GPP mobiles, henceforth referred as mobiles, need to..."). Teemu On Apr 23, 2013 9:15 PM, "Doug Barton" wrote: > On 04/23/2013 10:04 AM, t.petch wrote: > >> 'Cellular' has always been to me one of those quaint Americanisms that >> the rest of us have to put up with because America is, well, >> America:-( >> > > One could just as easily apply the reverse logic, where us Americans have > to put up with the fact that Europeans[1] make gratuitous changes to simple > terms just so that they can avoid having to use the same words Americans > use to refer to the same things.[2] > > Neither perspective is totally accurate, but consider this an FYI that > your gratuitously anti-American perspective is at least as grating to me as > you seem to find our use of language. > > My point being that rather than concentrating on how annoying Americans > are, it would be infinitely more useful to phrase your proposal as, "The > term 'mobile' is used much more commonly than the term 'cellular,' perhaps > the draft should reflect that usage," which is a perspective I think even > us annoying 'murricans would agree with. > > Doug > > [1] I am fully aware that most British don't consider themselves "European" > [2] Add bonus points for all such things actually invented in America > > ______________________________**_________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/**listinfo/v6ops > --089e013d1da86361c504db0b6b12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

My comment against simple term of "mobile" stems f= rom the idea that many kinds of devices can be mobile in sense of moving, b= ut also in the sense of using some mobile technology (3GPP, 3GPP2, WiMAX...= ) . This document applies only to mobiles in the 3GPP domain and hence that= should be stated clearly out (e.g. saying "3GPP mobiles, henceforth r= eferred as mobiles, need to...").

Teemu

On Apr 23, 2013 9:15 PM, "Doug Barton"= <dougb@dougbarton.us> wro= te:
On 04/23/2013 10:04 AM, t.petch wrote:
'Cellular' has always been to me one of those quaint Americanisms t= hat
the rest of us have to put up with because America is, well,
America:-(

One could just as easily apply the reverse logic, where us Americans have t= o put up with the fact that Europeans[1] make gratuitous changes to simple = terms just so that they can avoid having to use the same words Americans us= e to refer to the same things.[2]

Neither perspective is totally accurate, but consider this an FYI that your= gratuitously anti-American perspective is at least as grating to me as you= seem to find our use of language.

My point being that rather than concentrating on how annoying Americans are= , it would be infinitely more useful to phrase your proposal as, "The = term 'mobile' is used much more commonly than the term 'cellula= r,' perhaps the draft should reflect that usage," which is a persp= ective I think even us annoying 'murricans would agree with.

Doug

[1] I am fully aware that most British don't consider themselves "= European"
[2] Add bonus points for all such things actually invented in America

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--089e013d1da86361c504db0b6b12-- From jouni.nospam@gmail.com Wed Apr 24 04:48:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4372621F8F41 for ; Wed, 24 Apr 2013 04:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j46rY97US39Q for ; Wed, 24 Apr 2013 04:48:29 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 704E221F8F2C for ; Wed, 24 Apr 2013 04:48:28 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id t11so1600025lbi.39 for ; Wed, 24 Apr 2013 04:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=SglmHcC07KFhGGxGXIuhuKM3Fyh85bjjp7ha6xtT5NU=; b=EmoNOADBcozwzEwm2KXClWnRp6SLWqjao8jRMySJN/pw48MkOJghVUZAJUavtlhNj3 7e1W1rNYydAwwoyvVjPyPWlzQ0pc/N1M9MNo3DYTWLurR5e0T4uPd2pqHGVPvxIP+4Oc aXMs10YpQckWkW63UxHUpXwBWrm5nE0QVvBOF2CffIt2iNUgobgGI3ZfcQlB6zwXrFOz bfYqyknBOg/I8UNrV67Oa2I18Yn9OVtHZcVzlW8/vo2HNflfJWQFHpFlgY+/9WN6SNxA MnEb5FcQgG79xrLIN3c0MnkATnMTZq+M8ZkbmcGQTm2Uvs7gu3x2CCtdtyR+4mACg7uf h9EQ== X-Received: by 10.152.20.134 with SMTP id n6mr5691878lae.19.1366804107276; Wed, 24 Apr 2013 04:48:27 -0700 (PDT) Received: from [10.37.65.135] ([77.95.242.38]) by mx.google.com with ESMTPSA id q4sm1115259lbi.14.2013.04.24.04.48.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 04:48:26 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC86EB942@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 24 Apr 2013 14:48:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C682931C08B048B7A8645303FDC9F36EC86EB942@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-mobile-device-profile@tools.ietf.org" Subject: Re: [v6ops] Review of draft-ietf-v6ops-mobile-device-profile-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 11:48:30 -0000 Hi Med, Thanks for the response. I have few comments back. I deleted almost everything that I agreed with. See inline.. - JOuni On Apr 23, 2013, at 9:08 AM, mohamed.boucadair@orange.com wrote: > Hi Jouni, >=20 > Many thanks for the review. >=20 > My answers inline. > Cheers, > Med >=20 >=20 >> -----Message d'origine----- >> De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] >> Envoy=E9 : vendredi 19 avril 2013 10:08 >> =C0 : v6ops@ietf.org Operations; draft-ietf-v6ops-mobile-device- >> profile@tools.ietf.org >> Objet : Review of draft-ietf-v6ops-mobile-device-profile-01 >>=20 >> 5) Section 2 - Connectivity Requirements >>=20 >> REQ#2: The cellular host MUST support both IPv6 and IPv4v6 PDP >> Contexts. >>=20 >> o for a MUST requirement I would like to see the 3GPP release to >> which this applies. >=20 > [Med] Like for other requirements, we avoided to mention the release = as suggested by Mickael (check the v6ops ml archives). I would not typically care about the release here. But for this specific topic the 3GPP release thing is a mess. I would at minimum include a=20 note or warning that there is specific 3GPP release related details to consider. For example a note & reference to Section 6.2 of RFC6459 would suffice, I guess. >> o there are also cases where IPv6-only cellular host is justified, >> thus I would point back here in the text to e.g. Section 1.1 >> M2M scope clarification/narration. >>=20 >> REQ#3: The cellular host MUST comply with the behavior defined in >> [TS.23060] [TS.23401] [TS.24008] for requesting a PDP context >>=20 >> o The list of references neglect non-3GPP accesses (TS.23402). I am = fine >> with that but you should state it in e.g. Section 1.1 scoping that >> non-3GPP accesses except for some exceptions (Wi-Fi without 3GPP >> flavour) are out of scope. >=20 > Med: Section 1.1 states explicitly both 3GPP accesses and WLAN are in = scope. No need to have an explicit reference to TS.23402. Sorry for my sloppy wording but I was more concerned about stuff like eHRPD.=20 >>=20 >> cellular host will be configured with an IPv4 address and/or >> ^^^^^^^ >> o s/will be/MAY be. There is no guarantee that an UE would always = open >> two PDPs. >=20 > [Med] As suggested by Teemu "and/or" was changed to "or". As such, = "will be" is accurate. 'or' is OK with me. The further change in the next sentence from MAY to MUST is not. I would we ok with SHOULD (since 3GPP specs say here should, not shall). >> standard MTU setting due to inconsistencies in GTP [RFC3314] >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> o Expand GTP on the first occurrence. >> o It is unclear what the "inconsistencies in GTP" are. The RFC3314 >> definitely does not tell a thing about that. Also give a reference >> to a proper GTP specification(s). >=20 > [Med] re-used the same pointers as in RFC6459. It is still unclear to me what the inconsistencies are. >> The support of PCP is seen as a driver to save battery >> ^^^^^^^^^^^^^^^^^^^^^^ >> consumption exacerbated by keepalive messages. PCP also >>=20 >> o This is a strong statement. Do we have documented proof of that? >> PCP itself does not solve or even help that much the battery >> savings since the host side applications still need to coordinate >> among themselves and it is a different issue & problem. >=20 > [Med] The text only says "is seen as a driver to save battery. This = text is basically restating what is included on the base PCP spec: " = This helps reduce bandwidth on the subscriber's > access network, traffic to the server, and battery consumption on > mobile devices. " Fine. >> Recent tests revealed that IPv4 configuration is required >> to enable IPv6-only connectivity. Indeed, some cellular >> handsets can access a Wi-Fi IPv6-only network by >> configuring first a static IPv4 address. Once the device >> is connected to the network and the wlan0 interface got an >> IPv6 global address, the IPv4 address can be deleted from >> the configuration. This avoids the device to ask >> automatically for a DHCPv4 server, and allows to connect to >> IPv6-only networks. >>=20 >> o I would delete this and just state that "Failing to configure an >> IPv4 address on the interface MUST NOT prohibit using IPv6 on the >> same interface." > [Med] "Recent test.." is now changed to " Some tests..". I didn't = removed that text as it provides the context. I added the explicit = sentence you proposed. Ok fine. >> permanent interface identifier. [RFC4941] does not require >> any DAD mechanism to be activated as the GGSN (or PDN-GW) >> MUST NOT configure any global address based on the prefix >> allocated to the cellular host. >>=20 >> REQ#24: The cellular host SHOULD support ROHC for IPv6 ([RFC5795]). >>=20 >> o I would say which ROHC profiles SHOULD be supported. It makes no = sense >> to require all, since IMHO ROHC has limited benefit in 3G/LTE. I = would >> strongly recommend aligning this requirement to GSMA PRD.92. >=20 > Med: Profile 1 and 2 are explicitly included in the REQ now. And you also added the reference to the GSMA document? I think that is needed to give the justification for the crude scoping of profiles ;) >> requirements specified in [RFC6204]. >> ^^^^^^^ >> o I would suggest referencing to RFC6204bis since it has some = language >> that takes cellular network particularly into considerations. >=20 > Med: RFC6204 is sufficient. RFC6204bis has PD Exclude included among other finetuned DHCPv6 text. That was my reason for updating the reference. >> REQ#33: Applications MUST be independent of the underlying IP >> address family. >>=20 >> o I think SHOULD/RECOMMENDED with some stressing would be more >> appropriate. There could be cases where IP version specific >> software is justified, e.g. diagnostic tools and such.. Maybe >> "MUST be independent of the underlying IP address family, >> unless done purposely address family specific for a specific >> reasons." >=20 > [Med] IMO, adding exceptions will nullify the REQ. SHOULD here should be strong enough. Thanks. That was quite a lot :) From fred@cisco.com Wed Apr 24 22:11:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F4821F92FB for ; Wed, 24 Apr 2013 22:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.116 X-Spam-Level: X-Spam-Status: No, score=-110.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HktMCRMsQjeh for ; Wed, 24 Apr 2013 22:11:16 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0B42121F92BD for ; Wed, 24 Apr 2013 22:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=677; q=dns/txt; s=iport; t=1366866676; x=1368076276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pyMeAjrEc8zfI0urSMnax4k2i0roaa97s0Nn7U2zxO4=; b=aAxh2nA7q5daNOhlechmxyojXMkLqNtdGajbpbegJoGWsPJOiyyg+Ey4 HVmttkfMkwzwkcfAEYcn0lE5cPhi/jWs+Lq57uGGvXrR/BqnpXB9jHuyL UV/R7pKAra1EYJGh9Sl8PhqBGJPPdg6KyBFgdSKvrV2ZTUFInWX83rxWa E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALe5eFGtJXG8/2dsb2JhbABRgwaDJrs9gQIWdIIfAQEBAwF5BQsCAQgOFCQhESUCBA4FCId6AwkGtgUNiDKMWoIjAjEHgmthA4hYjGCNZYUfgw6CKA X-IronPort-AV: E=Sophos;i="4.87,548,1363132800"; d="scan'208";a="202824885" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 25 Apr 2013 05:11:15 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3P5BFmu025170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Apr 2013 05:11:15 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 00:11:15 -0500 From: "Fred Baker (fred)" To: Teemu Savolainen Thread-Topic: [v6ops] Review of draft-ietf-v6ops-mobile-device-profile-01 Thread-Index: AQHOQXNP2pSkLTxmDkSyr1vc0W64Pg== Date: Thu, 25 Apr 2013 05:11:14 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B8217E7@xmb-rcd-x09.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36EC86EB942@PUEXCB1B.nanterre.francetelecom.fr> <002901ce4044$9c739f60$4001a8c0@gateway.2wire.net> <5176CFC3.30502@dougbarton.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] Review of draft-ietf-v6ops-mobile-device-profile-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 05:11:18 -0000 On Apr 23, 2013, at 11:33 AM, Teemu Savolainen wrote= : > My comment against simple term of "mobile" stems from the idea that many = kinds of devices can be mobile in sense of moving, but also in the sense of= using some mobile technology (3GPP, 3GPP2, WiMAX...) . This document appli= es only to mobiles in the 3GPP domain and hence that should be stated clear= ly out (e.g. saying "3GPP mobiles, henceforth referred as mobiles, need to.= .."). I would make a similar comment about 'wireless'. To my small and unimaginat= ive mind, 'wireless' means 'without wires', which is an attribute of 802.11= , 802.16, 80.15.1, and 802.15.4...= From ietfc@btconnect.com Thu Apr 25 02:07:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B798321F9401 for ; Thu, 25 Apr 2013 02:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5niQL4D5xjv for ; Thu, 25 Apr 2013 02:07:06 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id DB98221F93EE for ; Thu, 25 Apr 2013 02:07:05 -0700 (PDT) Received: from mail121-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Thu, 25 Apr 2013 09:07:05 +0000 Received: from mail121-ch1 (localhost [127.0.0.1]) by mail121-ch1-R.bigfish.com (Postfix) with ESMTP id F38AD1E09E8; Thu, 25 Apr 2013 09:07:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -70 X-BigFish: PS-70(zzbb2dI98dI9371Ic89bh542I1432I1418I1a09J15caKJ1447Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz8275bh8275dh1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch304l1d11m1155h) Received: from mail121-ch1 (localhost.localdomain [127.0.0.1]) by mail121-ch1 (MessageSwitch) id 1366880824178991_3934; Thu, 25 Apr 2013 09:07:04 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail121-ch1.bigfish.com (Postfix) with ESMTP id 1F855240079; Thu, 25 Apr 2013 09:07:04 +0000 (UTC) Received: from DB3PRD0711HT003.eurprd07.prod.outlook.com (157.56.254.197) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 25 Apr 2013 09:07:02 +0000 Received: from DBXPRD0411HT001.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.255.183.36) with Microsoft SMTP Server (TLS) id 14.16.293.5; Thu, 25 Apr 2013 09:06:51 +0000 Message-ID: <023901ce4193$896dde80$4001a8c0@gateway.2wire.net> From: t.petch To: joel jaeggli , , References: <94C682931C08B048B7A8645303FDC9F36EC86EB942@PUEXCB1B.nanterre.francetelecom.fr> <002901ce4044$9c739f60$4001a8c0@gateway.2wire.net> <5176C945.9040203@bogus.com> Date: Thu, 25 Apr 2013 10:01:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.165] X-FOPE-CRA-SourceIpAddress: 157.56.254.197 X-FOPE-CRA-DRYRUN: 1207119;1 X-FOPE-BFA-SENDER: ietfc@btconnect.com X-FOPE-BFA-RECEIVER: v6ops@ietf.org X-FOPE-BFA-RECEIVER: draft-ietf-v6ops-mobile-device-profile@tools.ietf.org X-FOPE-BFA-RECEIVER: joelja@bogus.com X-FOPE-BFA-RECEIVER: mohamed.boucadair@orange.com Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: draft-ietf-v6ops-mobile-device-profile@tools.ietf.org Subject: Re: [v6ops] Review of draft-ietf-v6ops-mobile-device-profile-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 09:07:06 -0000 ----- Original Message ----- From: "joel jaeggli" To: "t.petch" ; ; Cc: Sent: Tuesday, April 23, 2013 6:47 PM On 4/23/13 10:04 AM, t.petch wrote: > That's a lot of work and a lot of changes, which makes me think I have > missed the boat but .... > > 'Cellular' has always been to me one of those quaint Americanisms that > the rest of us have to put up with because America is, well, > America:-( Indeed, even Wikipedia, which I would regard as the epitome > of American, goes so far as to reroute 'cellular phone' to 'mobile phone > also known as cellular' so mobile must be understood by some Americans! Cellular e.g. the 70s, at the time distinguished between VHF radio phone systems, and more geographically limited (e.g. cellular) services serviced by more than one transceiver... Parts of the united states have had radio mobile phone service since 1946. Joel Thanks for that. I suspected that there was something behind this that I was ignorant of and so it has proved. (I was thinking that perhaps the American use of mobile might include digital cordless, WiFi etc). As Jouni said, "use consistent wording" and that for me is paramount. As to what the wording is, then that is less clear - I would prefer 'mobile' with s1.2 spelling out exactly what that means, but using 'cellular' with s1.2 spelling out exactly what that means is an alternative. Or, since this is not about mobile or cellular devices in general, but only about 3GPP, should that be the word used? Either way, I do think that a beefed up s1.2 is needed, whatever term is used. Tom Petch > > So why go for cellular rather than mobile? And I see a mix of cellular > host and cellular device - are they different? (I note that in the > rfc-index, usage of 'mobile' vastly outweighs that of 'cellular'). > > At the very least, I think that s1.2 should be expanded to give a brief > summary of what you mean, what makes a 'cellular host' cellular and (if > not consistent with RFC1122), a host, ditto mobile network, etc etc > > Tom Petch > > ----- Original Message ----- > From: > To: "Jouni Korhonen" ; > Cc: > Sent: Tuesday, April 23, 2013 7:08 AM > > Hi Jouni, > > Many thanks for the review. > > My answers inline. > Cheers, > Med > > >> -----Message d'origine----- >> De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] >> Envoy=E9 : vendredi 19 avril 2013 10:08 >> =C0 : v6ops@ietf.org Operations; draft-ietf-v6ops-mobile-device- >> profile@tools.ietf.org >> Objet : Review of draft-ietf-v6ops-mobile-device-profile-01 >> >> Hi, >> >> I did a review of draft-ietf-v6ops-mobile-device-profile-01. Below are >> my comments. They are rather long, sorry about that ;) >> >> - JOuni >> >> --------------------------------------------------------------------- >> >> 1) General notes >> >> o The I-D mixes (throughout) PDP context, PDP Context, PDP-Context. >> suggest to use PDP-Context. (I have not noted any of those in >> the comments below) > [Med] Fixed. > >> o The I-D mixes (throughout) dual-stack and dual stack. Suggest >> to choose one style; like dual-stack. (I have not noted any of > [Med] Fixed. > >> those in the comments below) >> o The I-D uses both RFC3316 and draft-ietf-v6ops-rfc3316bis. Suggest >> to use only the latter one. > [Med] The text will be tweaked. > >> o The I-D uses a "mobile device" in places where it should really say >> a "cellular device". Use consistent wording. > [Med] Will check the text. > >> o The I-D uses a "mobile network" where it should really use "cellular >> network". In places where the network can be cellular or some other >> wireless technology, I would use "wireless network" as a generic >> term. > [Med] The text twill be checked. > >> o The use of GGSN and PDN-GW should have more consistency. For example >> using GGSN/PGW throughout.. > [Med] OK. > >> 2) Abstract >> >> This document specifies an IPv6 profile for mobile devices. It lists >> ^^^^^^^^^^^^^^ >> the set of features a mobile device is to be compliant with to >> ^^^^^^^^^^^^^ > [Med] changed to "This document specifies an IPv6 profile for 3GPP > mobile devices. It lists the set of features a 3GPP mobile device is to > be compliant with to connect to an IPv6-only or dual-stack wireless > network (including 3GPP cellular network and IEEE 802.11 network)." > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From sarikaya2012@gmail.com Fri Apr 26 05:38:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15A521F98C8 for ; Fri, 26 Apr 2013 05:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6e3MZZc5fQ2 for ; Fri, 26 Apr 2013 05:38:12 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id F1D4621F9888 for ; Fri, 26 Apr 2013 05:38:11 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id t11so3715391lbi.39 for ; Fri, 26 Apr 2013 05:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:date:message-id:subject:from:to:cc :content-type; bh=6ZkshhQkCL+SGpjbnzfA71ZgiM6QTJ7OuwBw66znArU=; b=UEXpPDbWPmm1S0xY+Mj9vq0FuH809CFDMSHpFEI+/JiFad92FdEatcq4/e0DmMcPIo oWP8X9G3qJV7i1tyYTYm3PQIXCPwQZ591TTluHSRV2X2G/MItmGQn5ZXpxIB8HIiCDRp 28TJ0iiIsEdfX9dlTuEOSokuJ/A+IO1hky1z1vr68LGc/MBDMOwrU+RtVAj4c/+wKGxZ Ky+zbvYAteEFJdPmto/0t8az5az6q6ziGeX5YRxtYYPWth9YkxM1lYw5PqUEGdnzmCtt WPp/Innyvm3X4bSMZx4Bd/EbMatvDNT17S4dv9l9pwDuO6jwbAnB4jICoGMQ33grbfqR c39Q== MIME-Version: 1.0 X-Received: by 10.112.150.228 with SMTP id ul4mr9687019lbb.132.1366979890737; Fri, 26 Apr 2013 05:38:10 -0700 (PDT) Received: by 10.114.175.140 with HTTP; Fri, 26 Apr 2013 05:38:10 -0700 (PDT) Date: Fri, 26 Apr 2013 07:38:10 -0500 Message-ID: From: Behcet Sarikaya To: Cameron Byrne Content-Type: multipart/alternative; boundary=047d7b342d28cd7b7b04db42ce4e Cc: v6ops@ietf.org Subject: [v6ops] 464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 12:38:13 -0000 --047d7b342d28cd7b7b04db42ce4e Content-Type: text/plain; charset=ISO-8859-1 Hi Cameron, What is the situation with iPhone 5 and RFC 6877? Regards, Behcet --047d7b342d28cd7b7b04db42ce4e Content-Type: text/html; charset=ISO-8859-1 Hi Cameron,

What is the situation with iPhone 5 and RFC 6877?

Regards,

Behcet
--047d7b342d28cd7b7b04db42ce4e-- From cb.list6@gmail.com Fri Apr 26 06:38:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6505E21F98D7 for ; Fri, 26 Apr 2013 06:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D5wma1oygkZ for ; Fri, 26 Apr 2013 06:38:28 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id BAEEF21F98C9 for ; Fri, 26 Apr 2013 06:38:27 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id z11so2199636wgg.32 for ; Fri, 26 Apr 2013 06:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uYwWsYwlLUEOXp4iFXw1JyGD2AJIjFuVOzei+skFkuU=; b=RVYI/gVaKvwf3ibvfvWTSCszyP4yKeKSdlJIl7LXwf45/ykwG8iXENPQ+58I4Sfkuh vZRzjQwHZF03zt6x9DEV2c9jnUnSzNka7C61r5ckxhGibi5aydH32OX4fzN21WroNjeU 1npWY1fBG/i0dVPUFV4vIOSbmlmF/GrhqlVloSiNbIM7ugVyoPjwjf2XZNDhZgKCPjaZ vtjoh3mSgQE3saY0/mOrjFz0Atkrc2NopQ2WLWeCANrLGBj6LNhNS2ft+sTYpiCrd7JF fT/kfbvamnh3281eH3XxtZ/34+68hV9TvKpZbPkNndC7SgLIfZSd85JKwQ3gVmXpRxYa uUNA== MIME-Version: 1.0 X-Received: by 10.180.88.33 with SMTP id bd1mr4049872wib.18.1366983055957; Fri, 26 Apr 2013 06:30:55 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Fri, 26 Apr 2013 06:30:55 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Fri, 26 Apr 2013 06:30:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Apr 2013 06:30:55 -0700 Message-ID: From: "cb.list6" To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=f46d0444e8fd78631504db438b89 Cc: v6ops@ietf.org Subject: Re: [v6ops] 464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 13:38:28 -0000 --f46d0444e8fd78631504db438b89 Content-Type: text/plain; charset=ISO-8859-1 On Apr 26, 2013 5:38 AM, "Behcet Sarikaya" wrote: > > Hi Cameron, > > What is the situation with iPhone 5 and RFC 6877? > Apple does not support it today and they don't comment on technology roadmaps. CB > Regards, > > Behcet --f46d0444e8fd78631504db438b89 Content-Type: text/html; charset=ISO-8859-1


On Apr 26, 2013 5:38 AM, "Behcet Sarikaya" <sarikaya2012@gmail.com> wrote:
>
> Hi Cameron,
>
> What is the situation with iPhone 5 and RFC 6877?
>

Apple does not support it today and they don't comment on technology roadmaps.

CB

> Regards,
>
> Behcet

--f46d0444e8fd78631504db438b89-- From internet-drafts@ietf.org Fri Apr 26 08:01:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A858921F9941; Fri, 26 Apr 2013 08:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVsWdBqzLaCq; Fri, 26 Apr 2013 08:01:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C0E21F9929; Fri, 26 Apr 2013 08:01:19 -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.44.p4 Message-ID: <20130426150119.22625.30231.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 08:01:19 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 15:01:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobi= le Devices Author(s) : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-02.txt Pages : 17 Date : 2013-04-26 Abstract: This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Fri Apr 26 08:08:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E618C21F9849 for ; Fri, 26 Apr 2013 08:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5yv6+J8c5zY for ; Fri, 26 Apr 2013 08:08:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 25A1021F984E for ; Fri, 26 Apr 2013 08:08:37 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 4170C26423C for ; Fri, 26 Apr 2013 17:08:36 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 29219238056 for ; Fri, 26 Apr 2013 17:08:36 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 26 Apr 2013 17:08:36 +0200 From: To: "v6ops@ietf.org" Date: Fri, 26 Apr 2013 17:08:34 +0200 Thread-Topic: I-D Action: draft-ietf-v6ops-mobile-device-profile-02.txt Thread-Index: Ac5CjwsgyPocp/g5QKujuaKKCxEbAQAAEnWg Message-ID: <94C682931C08B048B7A8645303FDC9F36EC9B49A47@PUEXCB1B.nanterre.francetelecom.fr> References: <20130426150119.22625.30231.idtracker@ietfa.amsl.com> In-Reply-To: <20130426150119.22625.30231.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.26.141220 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 15:08:38 -0000 Dear all, This version integrates most of the comments raised by Temuu and Jouni. Man= y thanks to them for their detailed and careful review. Much appreciated. Teemu/Jouni, please double check this version. Cheers, Med >-----Message d'origine----- >De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] >De la part de internet-drafts@ietf.org >Envoy=E9=A0: vendredi 26 avril 2013 17:01 >=C0=A0: i-d-announce@ietf.org >Cc=A0: v6ops@ietf.org >Objet=A0: I-D Action: draft-ietf-v6ops-mobile-device-profile-02.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the IPv6 Operations Working Group of the >IETF. > > Title : Internet Protocol Version 6 (IPv6) Profile for 3GPP >Mobile Devices > Author(s) : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : draft-ietf-v6ops-mobile-device-profile-02.txt > Pages : 17 > Date : 2013-04-26 > >Abstract: > This document specifies an IPv6 profile for 3GPP mobile devices. It > lists the set of features a 3GPP mobile device is to be compliant > with to connect to an IPv6-only or dual-stack wireless network > (including 3GPP cellular network and IEEE 802.11 network). > > This document defines a different profile than the one for general > connection to IPv6 cellular networks defined in > [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies > also features to deliver IPv4 connectivity service over an IPv6-only > transport. > > Both hosts and devices with capability to share their WAN (Wide Area > Network) connectivity are in scope. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-= 02 > > >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 hammondjohnson@hushmail.com Sat Apr 27 14:57:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F5221F98C0 for ; Sat, 27 Apr 2013 14:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k2G2d-eieqQ for ; Sat, 27 Apr 2013 14:57:24 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by ietfa.amsl.com (Postfix) with ESMTP id C36FC21F998E for ; Sat, 27 Apr 2013 14:57:22 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id BEAC51B5345 for ; Sat, 27 Apr 2013 17:54:00 +0000 (UTC) X-hush-relay-time: 215 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:54:00 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 7814AE6736; Sat, 27 Apr 2013 17:54:00 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:54:00 -0400 To: v6ops@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427175400.7814AE6736@smtp.hushmail.com> Subject: [v6ops] Biggest Fake Conference in Computer Science X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:57:24 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From fred@cisco.com Sun Apr 28 13:00:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2304B21F972C for ; Sun, 28 Apr 2013 13:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bad0SONaIkjg for ; Sun, 28 Apr 2013 13:00:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3433121F9668 for ; Sun, 28 Apr 2013 13:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=631; q=dns/txt; s=iport; t=1367179204; x=1368388804; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=9Gqm4igYnbMLSKTLd/12HVEsfhOG2B6ilqDE6ghhijg=; b=SvD4uv/ERXJ5r0bRfcKLxOXnHIx7PUE/O3qLRnD6nDWS+Hre0qLzg7ON 5w4uEnEsisxKpBtads2Jc+/f6ytutCF4ZXl7Fz1njVjbWXI3sEROO7jXO nsd4PDaHDeMODHnvwlyrpN0S2bQChEJ4WFcpt6edajWYrOT/l1OGhoqfS g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgGANt+fVGtJXHB/2dsb2JhbABTgwc2vkaBABZtB4IhAQQ6PxIBKhRCJwQODYgOvDeOaTGCdWEDqEiDEYIo X-IronPort-AV: E=Sophos;i="4.87,568,1363132800"; d="scan'208";a="204033946" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 28 Apr 2013 20:00:03 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3SK03TI020175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Apr 2013 20:00:03 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Sun, 28 Apr 2013 15:00:02 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-64share WGLC Thread-Index: AQHOREr4T78xADp5JEiBHylPFokFHQ== Date: Sun, 28 Apr 2013 20:00:02 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B8298F8@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: text/plain; charset="us-ascii" Content-ID: <754ED8E3EEE10F4E919703E7005C7E6A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 20:00:08 -0000 This is to initiate a two week working group last call of http://tools.ietf= .org/html/draft-ietf-v6ops-64share. Please read it now. If you find nits (s= pelling errors, minor suggested wording changes, etc), comment to the autho= rs; if you find greater issues, such as disagreeing with a statement or fin= ding additional issues that need to be addressed, please post your comments= to the list. We are looking specifically for comments on the importance of the document = as well as its content. If you have read the document and believe it to be = of operational utility, that is also an important comment to make. From jouni.nospam@gmail.com Mon Apr 29 02:14:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0A521F9D3E for ; Mon, 29 Apr 2013 02:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vw2+LK7L8TL for ; Mon, 29 Apr 2013 02:14:15 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 25C3121F9D3C for ; Mon, 29 Apr 2013 02:14:11 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p10so290426lbv.21 for ; Mon, 29 Apr 2013 02:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=gboTpc5dMR0P8zHIVcYsQzAa1vj8ao2NSsZI6CcRUhI=; b=qh9ilY4iGBsPoWsc0h2bjXZH1ngZJ0R0AwFwSl+PNPAl1Cq4tPtevQSPbPkDPVlujT fcFBYgj5DAX/DlrBUnJLwjhJq86wDj0rLJm0iTjTSVYRL9xuwTu7cBWpvISqUQX4EHO+ F3apgC0NRm3xH29vcSrN7bYH7DL9dmTY09o+/TAYNEHrC5tikokkhekQmdchyqAFyd1u PeuFxQoTRPvSzVERDW4VvuSAYPxgE8p30bK1p8Wv6jLz3FhDH7hbi4ph9c1pWfJYGALq dH9PsNphrWDq5pHdRTbxVwos8kHjoUYF9KmNzHozHkeFtUihV7f7oCbtzV1WZf6q8H3e et6Q== X-Received: by 10.112.136.129 with SMTP id qa1mr168092lbb.70.1367226850960; Mon, 29 Apr 2013 02:14:10 -0700 (PDT) Received: from [192.168.250.191] ([194.100.71.98]) by mx.google.com with ESMTPSA id sl5sm9060969lbb.10.2013.04.29.02.14.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Apr 2013 02:14:09 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC9B49A47@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 29 Apr 2013 12:14:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0E7B4004-EE77-4332-AA81-9616BB9FD500@gmail.com> References: <20130426150119.22625.30231.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EC9B49A47@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 09:14:16 -0000 Hi, I am OK with the latest revision. Thanks! - Jouni On Apr 26, 2013, at 6:08 PM, mohamed.boucadair@orange.com wrote: > Dear all, >=20 > This version integrates most of the comments raised by Temuu and = Jouni. Many thanks to them for their detailed and careful review. Much = appreciated. >=20 > Teemu/Jouni, please double check this version. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] >> De la part de internet-drafts@ietf.org >> Envoy=E9 : vendredi 26 avril 2013 17:01 >> =C0 : i-d-announce@ietf.org >> Cc : v6ops@ietf.org >> Objet : I-D Action: draft-ietf-v6ops-mobile-device-profile-02.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Operations Working Group of the >> IETF. >>=20 >> Title : Internet Protocol Version 6 (IPv6) Profile for = 3GPP >> Mobile Devices >> Author(s) : David Binet >> Mohamed Boucadair >> Ales Vizdal >> Cameron Byrne >> Gang Chen >> Filename : draft-ietf-v6ops-mobile-device-profile-02.txt >> Pages : 17 >> Date : 2013-04-26 >>=20 >> Abstract: >> This document specifies an IPv6 profile for 3GPP mobile devices. It >> lists the set of features a 3GPP mobile device is to be compliant >> with to connect to an IPv6-only or dual-stack wireless network >> (including 3GPP cellular network and IEEE 802.11 network). >>=20 >> This document defines a different profile than the one for general >> connection to IPv6 cellular networks defined in >> [I-D.ietf-v6ops-rfc3316bis]. In particular, this document = identifies >> also features to deliver IPv4 connectivity service over an IPv6-only >> transport. >>=20 >> Both hosts and devices with capability to share their WAN (Wide Area >> Network) connectivity are in scope. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-02 >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-= 02 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Mon Apr 29 22:59:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B796221F9C50; Mon, 29 Apr 2013 22:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7h3alwgmWyv; Mon, 29 Apr 2013 22:59:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6702F21F9B44; Mon, 29 Apr 2013 22:58:48 -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.44.p4 Message-ID: <20130430055848.18338.83714.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2013 22:58:48 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 05:59:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobi= le Devices Author(s) : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-03.txt Pages : 17 Date : 2013-04-29 Abstract: This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tsavo.stds@gmail.com Tue Apr 30 11:24:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3BD21F99D8 for ; Tue, 30 Apr 2013 11:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tskyZw0lE+5v for ; Tue, 30 Apr 2013 11:24:12 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1F64821F9AAB for ; Tue, 30 Apr 2013 11:24:10 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id h11so4250192wiv.2 for ; Tue, 30 Apr 2013 11:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=tbqLyoVw8uHH7JcC/9KNCtHWT2rXT3iWvdy7V1D+BBo=; b=tVvLymZRWlFWMHymJ+G6RSJ3HKrVby+Iqj12P2RTC6CAfupqFx4Gu2BtM/tpuvy5Qt n15VSkT10VtKlN4tire12rk6HkkVe6Wbqt8Xs/WMqT3WEEqCG+woShaFKKbqEETIO9C7 r3VTG0mp5PZMkkacFOm8g6Y79vN4khLYsCsc/SXIRbhGJ/mIKqPVPqFCWvG9VZe8im8w hZRxdVPuUFtstXZsLo9iAckaB1JM5B8MCGKz98jJUFcOv4TxwVvU5bcPfIPTMSkpUMMH sG3a3mjFSzMINOhsSOthJ567nfy/izT/ZTAN22XTwQ/d0xo7m7vEFs8kIeOQaeUOF0vG wI6Q== MIME-Version: 1.0 X-Received: by 10.180.182.135 with SMTP id ee7mr26549864wic.21.1367346250083; Tue, 30 Apr 2013 11:24:10 -0700 (PDT) Received: by 10.194.235.133 with HTTP; Tue, 30 Apr 2013 11:24:10 -0700 (PDT) Received: by 10.194.235.133 with HTTP; Tue, 30 Apr 2013 11:24:10 -0700 (PDT) In-Reply-To: <20130430055848.18338.83714.idtracker@ietfa.amsl.com> References: <20130430055848.18338.83714.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2013 21:24:10 +0300 Message-ID: From: Teemu Savolainen To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=089e01634fda85718504db981bd0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 18:24:14 -0000 --089e01634fda85718504db981bd0 Content-Type: text/plain; charset=ISO-8859-1 Thank you Med for these two additional fixes, seems to be OK! Teemu On Apr 30, 2013 8:59 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : Internet Protocol Version 6 (IPv6) Profile for > 3GPP Mobile Devices > Author(s) : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : draft-ietf-v6ops-mobile-device-profile-03.txt > Pages : 17 > Date : 2013-04-29 > > Abstract: > This document specifies an IPv6 profile for 3GPP mobile devices. It > lists the set of features a 3GPP mobile device is to be compliant > with to connect to an IPv6-only or dual-stack wireless network > (including 3GPP cellular network and IEEE 802.11 network). > > This document defines a different profile than the one for general > connection to IPv6 cellular networks defined in > [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies > also features to deliver IPv4 connectivity service over an IPv6-only > transport. > > Both hosts and devices with capability to share their WAN (Wide Area > Network) connectivity are in scope. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e01634fda85718504db981bd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thank you Med for these two additional fixes, seems to be OK= !

Teemu

On Apr 30, 2013 8:59 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the IPv6 Operations Working Group of the IE= TF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Internet Protocol Version 6 (IP= v6) Profile for 3GPP Mobile Devices
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : David Binet
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mohamed Boucadair
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ales Vizdal
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cameron Byrne
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gang Chen
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-mobile-device-pr= ofile-03.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 17
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-29

Abstract:
=A0 =A0This document specifies an IPv6 profile for 3GPP mobile devices. =A0= It
=A0 =A0lists the set of features a 3GPP mobile device is to be compliant =A0 =A0with to connect to an IPv6-only or dual-stack wireless network
=A0 =A0(including 3GPP cellular network and IEEE 802.11 network).

=A0 =A0This document defines a different profile than the one for general =A0 =A0connection to IPv6 cellular networks defined in
=A0 =A0[I-D.ietf-v6ops-rfc3316bis]. =A0In particular, this document identif= ies
=A0 =A0also features to deliver IPv4 connectivity service over an IPv6-only=
=A0 =A0transport.

=A0 =A0Both hosts and devices with capability to share their WAN (Wide Area=
=A0 =A0Network) connectivity are in scope.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6op= s-mobile-device-profile

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-mobile-= device-profile-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-v6ops-mobile-device-profile-03


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--089e01634fda85718504db981bd0-- From lorenzo@google.com Tue Apr 30 21:48:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA36721F8AC2 for ; Tue, 30 Apr 2013 21:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.062 X-Spam-Level: X-Spam-Status: No, score=-101.062 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdF5AFb0WjrZ for ; Tue, 30 Apr 2013 21:47:54 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E761721F872C for ; Tue, 30 Apr 2013 21:47:35 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id h1so1179323oag.3 for ; Tue, 30 Apr 2013 21:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=4gHldODfX9JuyrWBx/qggE8xZ5Sa3/+dYfEYm1RtMSE=; b=UTvDpfq1oAgLHlJTEjn5hVEuh/QJRy+dfZ1yV1py/DFQxbXPIytkw7Vl39Dbb1Lpkr bsj38NtXXy6CBJREHppRaLWqTWffoManySiZ87c25TT3ik8RAQGECdkW55eB73IlZIJy vaBnDHnnMpycNgRG+jV+OXMk5C5ATAzM4uxvbZl1cukBzYuegaP2CfWunzkay8tX5pLc LSDoAIx+EKQVosMZUBmePTIvjixf0poBeDMvyM8tiMfhY3Yt8i9c9j39T21xekmnrw0L KEGdcG5oOkAYeGkFSMongIpfH9OdNOv7dLAZYLTcI4xWK9vp/N6c09cOZcRyJ4NzEOzs Y+rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=4gHldODfX9JuyrWBx/qggE8xZ5Sa3/+dYfEYm1RtMSE=; b=D9FpLSfnuu3MxcQQDAnPflYMzHret4v5OlXrIrNpFEtR/EFL9M+kMy3Qtb64Ui4k9/ 6/MmwzYs7MK2uCPmSrftGzetMrzQHuiil3RDk5C5IuYwc9wOZ+QcxKxDSXYItChIcfdm RcTaP/rA/x1tZ3WdBdesWAqIGN8NGQBNej1Fosny9YPE0WNJPVNKxP8xfWnMFUh3Z4xd +pSP4wq7GoHblL0R6b/fk6xb0LDd+O3UzCTO0Gdqiq4wwYniHhFKLJeY2hwr2lYnpx9j JT1XHblWL8TQeCo4b0euShaXLCVN9vjfzPFxHDXljFE+Cb6m1XAmtqXHduuJs9UokdDl nAkw== X-Received: by 10.60.121.33 with SMTP id lh1mr283132oeb.98.1367383590158; Tue, 30 Apr 2013 21:46:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.104.165 with HTTP; Tue, 30 Apr 2013 21:46:09 -0700 (PDT) In-Reply-To: <20130430055848.18338.83714.idtracker@ietfa.amsl.com> References: <20130430055848.18338.83714.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Wed, 1 May 2013 13:46:09 +0900 Message-ID: To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=047d7b33d00429df8204dba0cd51 X-Gm-Message-State: ALoCoQnxWQHap4lJFDQTYSTvGT6fn8VLsB64i0zb/s1Rttt+Jx2M1kCpD74JzSeaDMvxnIHf1Yu6zgc5TIW2GQXJseD373rjvAHPTpAy9zROg/nvbiICXDzIQ7OQmI3Pzd0fD+fw62LffiPPgUx4sdz81LFNxBsDKEBqhO8Fj4piZBBiuQj5TcI5FO9BukY2IePLL6ij8NvC Cc: "v6ops@ietf.org WG" , i-d-announce@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 04:48:19 -0000 --047d7b33d00429df8204dba0cd51 Content-Type: text/plain; charset=ISO-8859-1 I object to the text "List in one single document all requirements a mobile device is to comply with to connect to an IPv6 or dual-stack mobile network." There are tens of millions of consumer devices out there that connect to dual-stack mobile networks every day, and yet none of them meet all the requirements of this document. Actually, I bet none of them even meet all the MUSTs in the document. So obviously, mobile devices don't need to comply with these requirements "to connect to an IPv6 or dual-stack mobile network". Please remove the text or reword it to reflect reality. On Tue, Apr 30, 2013 at 2:58 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : Internet Protocol Version 6 (IPv6) Profile for > 3GPP Mobile Devices > Author(s) : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : draft-ietf-v6ops-mobile-device-profile-03.txt > Pages : 17 > Date : 2013-04-29 > > Abstract: > This document specifies an IPv6 profile for 3GPP mobile devices. It > lists the set of features a 3GPP mobile device is to be compliant > with to connect to an IPv6-only or dual-stack wireless network > (including 3GPP cellular network and IEEE 802.11 network). > > This document defines a different profile than the one for general > connection to IPv6 cellular networks defined in > [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies > also features to deliver IPv4 connectivity service over an IPv6-only > transport. > > Both hosts and devices with capability to share their WAN (Wide Area > Network) connectivity are in scope. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b33d00429df8204dba0cd51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I object to the text "List in one single document all= requirements a mobile device is to comply with to connect to an IPv6 or du= al-stack mobile network."

There are tens of m= illions of consumer devices out there that connect to dual-stack mobile net= works every day, and yet none of them meet all the requirements of this doc= ument. Actually, I bet none of them even meet all the MUSTs in the document= .

So obviously, mobile devices don't need= to comply with these requirements "to connect to an IPv6 or dual-stac= k mobile network".

Please remove = the text or reword it to reflect reality.



On Tue, Apr 30, 2013 at 2:58 PM, <internet-drafts@ie= tf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the IPv6 Operations Working Group of the IE= TF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Internet Protocol Version 6 (IP= v6) Profile for 3GPP Mobile Devices
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : David Binet
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mohamed Boucadair
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ales Vizdal
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cameron Byrne
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gang Chen
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-mobile-device-pr= ofile-03.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 17
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-29

Abstract:
=A0 =A0This document specifies an IPv6 profile for 3GPP mobile devices. =A0= It
=A0 =A0lists the set of features a 3GPP mobile device is to be compliant =A0 =A0with to connect to an IPv6-only or dual-stack wireless network
=A0 =A0(including 3GPP cellular network and IEEE 802.11 network).

=A0 =A0This document defines a different profile than the one for general =A0 =A0connection to IPv6 cellular networks defined in
=A0 =A0[I-D.ietf-v6ops-rfc3316bis]. =A0In particular, this document identif= ies
=A0 =A0also features to deliver IPv4 connectivity service over an IPv6-only=
=A0 =A0transport.

=A0 =A0Both hosts and devices with capability to share their WAN (Wide Area=
=A0 =A0Network) connectivity are in scope.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6op= s-mobile-device-profile

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-mobile-= device-profile-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-v6ops-mobile-device-profile-03


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b33d00429df8204dba0cd51--

Hi Teem= u,

 

Please see inline.

Cheers,

= Me= d

 

De : Teemu Savolainen [mailto:tsavo= .stds@gmail.com]
Envoy=E9 : lundi 22 avril 2013 11:51
=C0 : BOUCADAIR Mohamed OLNC/OLN
Cc : v6ops@ietf.o= rg
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d= evice-profile-01.txt