Re: [v6ops] The bottom is /112

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 23 November 2020 09:03 UTC

Return-Path: <pthubert@cisco.com>
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 C47863A165D; Mon, 23 Nov 2020 01:03:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.72
X-Spam-Level:
X-Spam-Status: No, score=-7.72 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=gcCA+sqE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZbmTGUcb
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-0w2wUk5Tle; Mon, 23 Nov 2020 01:03:50 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B4F3A1450; Mon, 23 Nov 2020 01:03:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9336; q=dns/txt; s=iport; t=1606122230; x=1607331830; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=A4UOZ15d3Oowtb9yJvx6Rt39ydOtPHPFoCWGF/sLAL8=; b=gcCA+sqEtmFZwBZ731h2NUbnCrAdXSYqTy8cgCp0Rv7U+nlJO57EF+Kl CGimX99jpfelACOerzH/h7F9f8q7xiB06lyQl/xQte1J23D6NT6g7l9iL jYfObT2gu8Q7LoqdjHlfH30Trxj1lQOp8gn9cGBMNaP0Mr7B09cT6ICKq 8=;
X-IPAS-Result: A0CHBwC7eLtffY9dJa1fAx0BAQEBCQESAQUFAUCBT4FSKSh7WS8uCoQzg0kDjVqKFY5vgUKBEQNUCwEBAQ0BARgLCgIEAQGESgIXghQCJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGPAyFcgEBAQEDAQEQEREMAQEqAgIGAwELBAIBCAcKAQMBAQECAiMDAgICHwYLFAECBggCBAENBQgTAwEDgwWCVQMuAQ6fBQKBPIhodoEygwQBAQWBMwGDdA0LghAJgQ4qgnOCZk5CgQaFURuBQT+BEUOCTz6CG0IBAQKBKAEMBgEJGhUKJoJQM4Isk3GkBFUKgm6WC4U1gxqKGZRSk1yCAYtyjjaENwIEAgQFAg4BAQWBayFpcHAVO4JpCUcXAg2OHwwFEoECAQ2CPoUUhUR0AgE0AgYBCQEBAwl8iweBNAGBEAEB
IronPort-PHdr: 9a23:k+1m/BSV/hg7Y5OChknFd5iPq9psv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESQBNmJ5PdNiu6QuKflCiQM4peE5XYFdpEEFxoIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFLXq3y2qzUVH0a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR6arw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,361,1599523200"; d="scan'208";a="612917608"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Nov 2020 09:03:48 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AN93mYM004070 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Nov 2020 09:03:48 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Nov 2020 03:03:48 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Nov 2020 03:03:47 -0600
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 23 Nov 2020 03:03:47 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hoti23TXaFfMGlpuv7JvLu8vr4Ub9W5So6ulRhr0ag3Pv9mzJAU9aH0GZ777bj1ENhKLquKw/wYns17/I/etn1+iGobd5G72RvPHq/sRiUrf0sLzVdpOD36OH0pDKjpurQukFYroKK/fZRTCcdrDRfkihLM20DiTDWnjTh/1prA1PtbAtw43IktyHsu994SmmAjAxbL2KvV4/XmeuIwfdUQzhgqbkaLTKM2TM3vgLZ+CrUkEAoSO5jFZ2XuNhQShnQOZhkwb+vHa02X/9brmZVz2N/gO79IS8lAIV/AMXWPYdDIrgpsxKejae520rDlp3ZZhlLrsqnZio2vYTnuhpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A4UOZ15d3Oowtb9yJvx6Rt39ydOtPHPFoCWGF/sLAL8=; b=O67vzFAlUz6KcsqX5xtTI1xpghXANa2Wr05roE/9RTLKZEbFlY14PVSCejFMnBZOhjJvaurgx4dPyluRj87AZV5Bp7Jr+XC9lg60lKYeVQTrSsWGGT7MptvlyPCAWCtVoFiLMIHIrVZswRE+KC7kZNMLkPT9wG5TE7PQSuq0oghCZVWRKHfq3Mc66zhgPhXWb8h8WDgdVmVWr5JMZcTJQ2OEr55/Yjy4cUovBcgieVuNWWjEqWEPHTdUYMzk3vALetUAwG5hHZ2MLHPTa5BDSODvHqiOAPZOCubCVI+OFQZXHXQZUojs9qRuzmgL/JrUj7pTiaYR1RN3eInRyEaeiQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A4UOZ15d3Oowtb9yJvx6Rt39ydOtPHPFoCWGF/sLAL8=; b=ZbmTGUcbBHVbiI95kyXK4Unz15NDX4hLNAiS6r3NIvF96vbL+XDaSLTJZAT0KbCfrkrP+j1htz3xzBhedB8KX7uVDap8Isp6mzy36SDFokElYyU4DxsTX+5doYzEgSrLMKHZgs8oM2azKtI/iseHEpL/ntPdS8i4MHfgJpjw0/Y=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MW3PR11MB4585.namprd11.prod.outlook.com (2603:10b6:303:52::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Mon, 23 Nov 2020 09:03:46 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Mon, 23 Nov 2020 09:03:46 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Gyan Mishra <hayabusagsm@gmail.com>, "otroan@employees.org" <otroan@employees.org>
CC: IPv6 Operations <v6ops@ietf.org>, 6MAN <6man@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Thread-Topic: [v6ops] The bottom is /112
Thread-Index: AQHWvsaGXsDvNQUAW0OOJ7Lq2qz76anVa8aw
Date: Mon, 23 Nov 2020 09:03:29 +0000
Deferred-Delivery: Mon, 23 Nov 2020 09:02:53 +0000
Message-ID: <CO1PR11MB488152661E56DEE4EED016FAD8FC0@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <CABNhwV3fj-e9bEemivcNovnD3SZvKm8ZjFKp7BmusnPcgyznFQ@mail.gmail.com> <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <CABNhwV19neE3U_AisNp2nDUF4bWB8P8xHNEznDevZLE9amFTRA@mail.gmail.com> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <CABNhwV3bCss9y7cT6w2i+LKWBh1viPSXBM-CTaK+GVDyPS2D8w@mail.gmail.com> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <CABNhwV0-FZpPs84+RVB81=5H5QCEaxF0EUj9tcV+bdOu00RE2A@mail.gmail.com> <a8306401-3f2d-9284-804e-ab703d837426@gmail.com>
In-Reply-To: <a8306401-3f2d-9284-804e-ab703d837426@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.220.38]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 57d9db55-fa72-4bdb-de4f-08d88f8eaf4f
x-ms-traffictypediagnostic: MW3PR11MB4585:
x-microsoft-antispam-prvs: <MW3PR11MB4585DFD558AE96261A7A5960D8FC0@MW3PR11MB4585.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: teFUU+4HnZ/3PaOKAcRIZCZm4lFopjZ/q6cCDNjbk+Nu4b4d3f6RRT/+CbeKI170k9rf/QX9uMppfQV9PM2EMR54QynOAgy6iYcWd+uubZ48NJB4JKBDRn50TrOjjr6lJX4ASo3G6DX0uNuLAeyymn00p5lAnBspLTGhtutP13Dr3xwUiqSeNGd6j6KGmhMT8M+BMRRP7H+nbB8J7BoJCZcDVVBaaN0HRu5dUf9vFhMTpkCarA7R20KReGAi8Q0t88Bd+y5fhFWEg5uooBjpFRPCjkoWPx8Mh645r1NxRIJq8Ixpn6Jmz/LbIbRpdflDKY/0Sw+JFf+5WNI5eRDw6jeIXifjEnAIuFf7o158NkrwWPu/DPrAabjY32PTih+9Q6BMkZcDbdFoTdnWAGwgVg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(136003)(346002)(376002)(396003)(55016002)(52536014)(110136005)(66946007)(54906003)(478600001)(83380400001)(8676002)(53546011)(6506007)(186003)(66476007)(9686003)(64756008)(66556008)(26005)(316002)(66446008)(86362001)(76116006)(6666004)(66574015)(4326008)(33656002)(966005)(71200400001)(5660300002)(8936002)(2906002)(7696005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: m3mw28mK/rjhdCJHzO3vfjMo7UUncGBtcUDWojiqG3X262bWm9ETAfSt6sFK8W/MTKaKGjh5HB34APJ50rqi1rlXEraN9c7aTxH1KpDUFLxhlUmuBgnLGYBc/Y2vHtK7l8LF+BTqDmgSjKkxKXijChh+l4o4YWsPPdxqtAZTZQ7LqFFA3xDopM1alzeBIwuxwiw24kX2aJ74zjO7jJNEbG83qCDOGud6L8dHxC9qVR6lgejlkEdv55NorLJq4kax+gfAcR8vkghtUUnmgmSUj02HQjo99lCc7dT4oPIRLgspoB70IIFMOVmgT/hRbtpyrCm7s7CqxCcQzCfoXeAOR+W44NHN993cmTSeiNNb1fQLW/XE2d5lF17VvMtfuvtHdrvJBRHDfbEyurCNm0jUa1tmSCEcivKmQveX0bilKE494chjMjwMEPS5WDPe7JXdjoLBF8Is56NypzZXHCQjZP/nQLRIhbB7HzweG9ZLt2t42QiglpZRUebxALuDiy2x3WGTDkUemnDuELXBRIwH2rKEXev70nEz7jkJNzPtH9tcwiIBKJ0Jf7KhhWKos9C1niln7racKKWN7ELaTg8iIENsPJA4lPkT/WusryjVkMAxIgNvJ+ihnU4pw8srjHDWRKa4q+lt+2clqd/V9FmDA0iYU/jfAdMjsOCv7MifJFpwLhndUxrdzI9f9mJJhn+BVTc9oL32F7EiW3VEj2YX5aH53NKvhN8xdpNNn1gzUrnnGqj5x0wu4J8eMVvRTU1gr+dCrmwdjTt2HwVEzAe/A4b2o0wvPP+eHTHi8X9MzybDQggjrklbBIyWjB3x9odJ+CUdaios3tNiTs11jvIa6okZUCygnaX8kE3wE+mZb0pZZgn08nSmB9K/AJyZWPmFVTaoXjbukYLUxFzeC5na5w==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 57d9db55-fa72-4bdb-de4f-08d88f8eaf4f
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 09:03:46.1344 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MVyTFkRuF7QsosrMe1Ew/YH15db3s4O+dxfEUPycKZQVMIWT/SBDu5U029SZNFr9Q0WZZZZwh6tiIN9G5CHzxQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4585
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/8Y5ynXlPxWww9Dwv2snVnZuNBEA>
Subject: Re: [v6ops] The bottom is /112
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Nov 2020 09:03:53 -0000

Hello Brian

Please note that RFC 8929 would work there too -that's proxy ND with the backbone on the Wi-Fi link and the wireless access on the 3GPP link-, used in the routing proxy mode - that's when the links are not bridgeable-..
Basically the phone as a routing proxy installs host (connected) routes towards the 3GPP link for the addresses present there, and defends those addresses over the Wi-Fi Link.
On paper the result is similar to RFC 7278, but the method is a bit different since internally it relies on ND proxy as opposed to anycast. Arguably the phone would self-assign another global address on the Wi-Fi link, if it cares to have one at all on that link.
Bottom line is yes, I agree we should consider the applicability of what we have before we start breaking things down.

Keep safe;

Pascal

> -----Original Message-----
> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Brian E Carpenter
> Sent: jeudi 19 novembre 2020 23:50
> To: Gyan Mishra <hayabusagsm@gmail.com>; otroan@employees.org
> Cc: IPv6 Operations <v6ops@ietf.org>; 6MAN <6man@ietf.org>; JORDI PALET
> MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
> Subject: Re: [v6ops] The bottom is /112
> 
> And if we had left the boundary at /80, as it was in 1995 (RFC1884), would you
> now be arguing for /96, since in that case 3GPP would have settled on /80?
> 
> Sorry, but this is exactly and precisely a 16-bit jump in the race to the bottom.
> And it breaks all existing SLAAC hosts on the way.
> 
> The problem here is caused by 3GPP, but a solution like Cameron's should work
> for everybody with minimal changes.
> 
> Regards
>    Brian
> 
> On 20-Nov-20 11:03, Gyan Mishra wrote:
> >
> >
> > On Thu, Nov 19, 2020 at 10:33 AM <otroan@employees.org
> <mailto:otroan@employees.org>> wrote:
> >
> >
> >
> >     > On 19 Nov 2020, at 14:58, Gyan Mishra <hayabusagsm@gmail.com
> <mailto:hayabusagsm@gmail.com>> wrote:
> >     >
> >     > You would need a new option. It would likely be useful for the requesting
> router to indicate interest in the option. Even hinting at what prefix size it was
> expecting.
> >     > Now can you explain to me again the reasons why this approach is better
> than using the existing DHPCv6 protocol packets?
> >     >
> >     >     3GPP gateway does not support DHCPv6
> >
> >     3GPP gateway doesn't support new option. What's your point?
> >
> >
> >
> >     The point of the v6ops presentation and this email thread is how to “extend
> a /64” in the 3GPP use case  in slide 1 of the deck you compiled a list of options
> and of the two I had highlighted in red were the 64share v2 Cameron’s option
> and the variable slaac option.  So on the call this morning Lorenzo shot down
> 64share v2 shorter prefix option as even if the 3GPP architecture was updated
> to support longer prefixes and even is the 3GPP gateway was able to send a
> shorter prefix with A flag not set, all mobile devices per Lorenzo’s point would
> be broken as they would not accept the shorter let’s say /56 prefix to build the
> slaac 128 bit address.  So the bottom line is the 64share v2 won’t work unless
> we update RFC 4291 and remove the 64 bit boundary.
> >
> >  So we are back to square uno - no viable solution
> >
> >  So now we had thrown out the longer >64 due to race to bottom worries
> which I and others believe is Fud and as described in slide 10 of the v6ops “race
> to the bottom slide”.
> >
> > So a happy medium /80 fixed boundary I came up with that I think solves a lot
> of the issue and not just the 3GPP initial segmentation of downstream devices
> problem statement.
> >
> > Since we have to update RFC 4291 for 64share v2 to work anyways to allow
> for shorter prefixes, why not instead create a new bottom at /80 giving 16 bits
> more of prefix length and shrinking the IID down to 48 bits.  Doing so you would
> not even have to update the 3GPP architecture as I don’t know if that would fly
> or not.  Also this solves a few other problems at the same time.
> >
> >
> > As I mentioned in the v6ops deck presented that vlsm 0 to 128 is mainstream
> for operators for static addressing on router and switch infrastructure and
> dhcpv6 subnets longer prefixes for network infrastructure appliance clusters,
> NFV/VNF virtualization and server farms.  On host subnets where there is a
> chance of mix of slaac hosts with dhcpv6  devices the prefix length is stuck at
> /64.  So on these mix addressing host subnets we cannot do longer prefixes
> following our ND cache hard limit mantra to prevent ND cache exhaustion issues
> as described in RFC 6164.
> >
> > So with the /80 new fixed boundary shifting prefix length 16 bits longer and
> shortening the IID by 16 bits gives resolved the 3GPP issue which 64share can
> work as is and subtending to downstream devices will now work as a /64 is now
> equivalent to a /48 with 64k /80s.  Also BCP-690 for broadband not all
> operators have adopted the shorter prefix lengths /56 or /48
> recommendations  and now that’s not an issue as the /64 would now suffice.
> >
> > From an operators perspective that gain allows at least for 3GPP massive
> growth and subtending with a single /64 allows the operators such as Verizon
> with massive subscriber base worldwide can stay with current allocations and
> don’t have to ask for /10.
> >
> > As 5G gets rolled out with Enhanced VPN framework and Network slicing
> paradigm, the demand for shorter blocks and wearable multiple /48 will be our
> new reality.
> >
> > Making that 16 bit shift now to /80 making a /64 the new /48 will give
> broadband and 3GPP subscribers a ton of space to subtending their networks
> we would be set for the future.  Especially with IOT the demand for subtending
> will continue to grow astronomically.
> >
> > Also IANA does not have to get start in allocating the other /3 and other
> available blocks.
> >
> > Lots of problems being solved here with a fixed /80 new boundary.
> >
> > Also with the existing random IID generation schemes which we have tested
> on Linux kernel can do longer prefixes using RFC 4941 privacy extension or RFC
> 7217 stable IID.
> >
> > Win-Win for all.
> >
> >     Ole
> >
> > --
> >
> > <http://www.verizon.com/>
> >
> > *Gyan Mishra*
> >
> > /Network Solutions A//rchitect /
> >
> > /M 301 502-1347
> > 13101 Columbia Pike
> > /Silver Spring, MD
> >
> >
> >
> > _______________________________________________
> > 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