Next step? [Re: [v6ops] The bottom is /112]
Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 21 November 2020 03:00 UTC
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F783A1071; Fri, 20 Nov 2020 19:00:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level:
X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 qunjaKtzOucJ; Fri, 20 Nov 2020 19:00:20 -0800 (PST)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4460D3A106D; Fri, 20 Nov 2020 19:00:20 -0800 (PST)
Received: by mail-pf1-x430.google.com with SMTP id w6so9734836pfu.1; Fri, 20 Nov 2020 19:00:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Ve5gle+j3fo16dTatGMn6v1+cVGcnJmbVzdyFne09Bs=; b=Doq201m5zPmoemq3ooYG9v1RuG/M0G1aqBKyB2EN8mWonQoumJNluGy1d5I4E67Rd9 cCrRCagzRzvwFrhNZdiWnPZJfF2P1fPe5LVdpOOnKCsyKZe2hkgvbuGvsqfnWrcjU/2j 60KAwVFoW+l4K6O5r2Jon7hKFjXql5tbKdVQPHgXIDgPilcMVr/scFxdaZ0X7Zz/AE5n 7rpGdKh4CCl+0KqpAMDaX0YzYjJVTEjYtqeAvvDy0da/puXry0/9EBpO9gRlDXVvmidl C83XAWaFSOBR3B9dFT1TF1S3kVWPEYjJ/hqpejDIiZku2iY7VA2GC3z58UomqsDvCrGQ y2vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ve5gle+j3fo16dTatGMn6v1+cVGcnJmbVzdyFne09Bs=; b=HK3pLVM7wAC7nGdcsDIRWM/PQ7lMx8G1jVA19rkY3V5NyxZH/fCg++YLhBp8nolvTr tI2s5ZWsOz2pnjwao9zOPKc8e6s8N0Bn3BK8k9pxlJaxUWlkOgcln1LO933b0Ipu/swz /aoop3nlS2AgtGYqnA4buVkk/jAmHBRvTAXtr14dwYzkeIkDmSBzleiGg+4JmXs70l2y idHSA90QuIZmmU7o37q688MMDTfZJ/31YdTSXHHYFxPBMH84sTT1znRkBTGMqD/LNQqd H5JhosMRBqXzU5UR5DvsnpcmeQMcvd4W8dYWDv+uA/cPEtWTZFRk3zFqBR3KJVddSTyS IxSQ==
X-Gm-Message-State: AOAM5324A3lmIUbCeKzZuXtVMD7XMde/TRSkJNkJdJM6cKWYqFDSSqN9 HNxU5Y2tHdC8UnQLgjr2ohrjKhECnzl+bQ==
X-Google-Smtp-Source: ABdhPJwIm6EjtcogNRDwR6y/WAICtJ7wQYsP8wE5QE0n+Eb1PySLuzTIQ2MO2sdyzPcTpN8wwLdXEg==
X-Received: by 2002:a17:90a:2c2:: with SMTP id d2mr13402259pjd.36.1605927619065; Fri, 20 Nov 2020 19:00:19 -0800 (PST)
Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id v7sm5177755pfu.39.2020.11.20.19.00.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2020 19:00:18 -0800 (PST)
Subject: Next step? [Re: [v6ops] The bottom is /112]
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: IPv6 Operations <v6ops@ietf.org>, 6MAN <6man@ietf.org>
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> <fb87c22c-388d-0492-1ea7-018655353f9b@joelhalpern.com> <CABNhwV0TbS7Kiynb=jvczJFDyy=uMfd-he+d0ii7aU5AnsUKeA@mail.gmail.com> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <CABNhwV1pSiEuaOZGN5ErR=KETjD1fVb58YM1EEd+mf7RtOenQw@mail.gmail.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com>
Date: Sat, 21 Nov 2020 16:00:13 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZoQ8pWGpj3ikyLiXbRsitGYdUds>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Nov 2020 03:00:23 -0000
Joel, It seems to me that it's high time to draft a liaison statement to 3GPP, observing that: (1) There is a serious problem for the design and implementation of 5G-based IPv6 "hot spots" and CEs [which is where this conversation started]; (2) Although the best solution is not yet obvious, defining and standardizing it will require a joint effort by the IETF and 3GPP. Followed by a proposal to form an ad hoc joint design team. Regards Brian Carpenter On 21-Nov-20 14:46, Joel M. Halpern wrote: > The nesting got me lost, so I will top post my take on the answer to the > one quesiton I could understand. > > I believe you asked what I think would need to be changed to permit the > delegation. > As with anything, the real things that need to change are the devices in > the network. > > With regard to IETF standards, what is proposed is a change to RA. > There are several possible changes. None of them require a change to > the IPv6 addressing archtiecture, as the addressing structure remains as > it is. > As for the exact mechanism, at the moment I lean towards Ole's proposal > of using a new option in his generic option mechanism. But I am not > wedded to that answer. > > And of course, to get this supported in mobile environments we will have > to work with 3GPP and make sure there are no other hidden issues. > That's the way we do things. Work together. > > Changing the prefix length to /80 is technically also possible. It does > a lot more violence to my understanding of the architecture and software > structures that go with it, and is a very limited and narrow solution to > the problem. > > Yours, > Joel > > On 11/20/2020 7:58 PM, Gyan Mishra wrote: >> Hi Joel >> >> In-line >> >> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern <jmh@joelhalpern.com >> <mailto:jmh@joelhalpern.com>> wrote: >> >> Gyan, separate from Ole's comments about the difference between address >> assignment and delegation, I have another problem following the >> reasoning below. >> >> Yes, the proposal for using shorter prefixes to enable UE to perform >> delegation will require changes to the UE. >> >> Gyan> Agreed. So that change would be to RFC 4291 64 bit boundary >> to allow for longer prefix. Do you agree? >> >> If you don’t agree what do think the change would be to allow the UE to >> accept shorter prefix from the 3GPP gateway? >> >> >> But I do not see how that is relevant to any choice we are trying to >> make. >> Any solution that enables UE to delegate addresses (in the sense that >> they lack the capability now) willr equire changes to the UE. >> >> >> >> Gyan> If the UE receives a /56 via RA it could delegate /64 to >> downstream devices. No change needed to delegate /64, however a >> change is needed to accept /56 via RA. >> >> >> If 3GPP gateway supported PD - problem solved but that’s not the >> case and that does not sound like it will ever change even with 5G. >> >> Gyan> The UE needs to be able to accept shorter prefix. That’s the >> IPV6 specification change that requires removal of the 64 bit boundary. >> >> Yoru >> proposed change to the SLAAC length if anything does more violence to >> the software (depending upon the exact software architecture.) >> >> >> Gyan> What violence to software. There would be more violence to >> software if we removed the 64 bit boundary and allowed slaac to support >> any vlsm prefix lengths. >> >> My /80 proposal would just shift the boundary 16 bits to /80. >> >> Hosts on the same subnet with two different masks would not be on-net to >> each other as on different subnets. The router would be configured with >> the two subnets /64 and /80 subnet to support the two device types. >> The solution would be a simple RA PIO flag that is set and older hosts >> not upgraded would be backwards compatible and so would only support 64 >> bit boundary by ignoring flag. Hosts upgraded to support would >> understand the flag and be able to support longer mask up to /80. >> >> >> >> So I do not follow how you got to your conclusion. >> >> Yours, >> Joel >> >> On 11/20/2020 5:27 PM, Gyan Mishra wrote: >> > >> > (top posting) >> > >> > As I would like to clear the air as well as get to the crux of >> the v6ops >> > presentation development results as well as next steps for this >> draft >> > and the 6man variable slaac solutions draft: >> > >> > >> > This thread was in light of Lorenzo kindly pointing out that >> upgrading >> > 3GPP is not all that needs be done for Cameron’s 64share v2 to >> work - as >> > all mobile devices would stop working- as slaac would not would be >> > effectively broken. >> > >> > The mobile device would receive a shorter prefix let’s say /56 >> but not >> > know what to do with it since it’s expecting a /64. >> > >> > So that a major gap and the only solution is updating RFC 4291 >> removing >> > the 64 bit boundary allowing for shorter prefix and now as well >> longer >> > prefixes to work and in that respect now provide the much needed >> parity >> > with static and DHCPv6 which can do any prefix length. >> > >> > So that is a drastic change to RFC 4291. However, in light of this >> > development on the v6ops 109 call, my balancing act of best of both >> > worlds and also to keep everyone happy to make this a WG effort >> for this >> > change by proposing in the subject heading /80 fixed boundary and >> not a >> > variable slaac change allowing all bits vlsm. >> > >> > Basically stealing 16 bits for network prefix out of the IID, still >> > keeping the fixed boundary so longer than 80 would NOT be allowed. >> > >> > A /64 would now be equivalent to a /48 with now 64k /80’s. >> > >> > This /80 would keep the operators and law enforcement happy as >> now 16 >> > bits less helps traceability but is still long enough for 48 bits of >> > privacy to IP correlation by attackers. >> > >> > This /80 would be a nice optimal balance as it would keep wired >> > broadband and mobile handset customers happy respecting their >> privacy as >> > the 16 bits less of heuristics is minimal change that will impact IP >> > correlation by attackers. >> > >> > The IID as it’s less than the current 64 bit cannot use MAC based >> EUI64 >> > IID, which is not a problem as Mac based IID is not recommended >> as most >> > all manufacturers use RFC 4941 and I believe Linux flavors some use >> > stable IID RFC 7217. >> > >> > So now the 48 bit IID would require a random IID generation >> schema so >> > can use either RFC 4941 privacy extension or RFC 7217 stable IID to >> > generate the 48 bit IID. >> > >> > 3GPP subtending would now work issue mentioned in the problem >> statement >> > draft without even having to use 64share as now longer prefixes >> up to >> > /80 would be supported allowing for further segmentation of >> downstream >> > devices. >> > >> > This also would help wired broadband and soon fixed 5G broadband >> > proliferation where operators in light of BCP RIPE-690, are sill >> > allocation via BNG gateways a /64, now operators can stay as-is, >> as the >> > /64 would now be allowed to be further segmented supporting 64k >> /80s, >> > way more then enough for SOHO. >> > >> > This would allow 64share if used by 3GPP operators to work and >> would not >> > require the 3GPP specification to be updated. We don’t know even >> if the >> > 3GPP architecture specification can be updated to support shorter >> > prefixes and if the 3GPP consortium of operators would agree to >> it. So >> > that is all theoretical of that change is possible. >> > >> > As with 5G with Enhanced VPN framework SR steering of high priority >> > traffic, traffic isolation and Network slicing capabilities becomes >> > mainstream and will soon be a real world reality and as fixed 5G >> > broadband proliferation takes off and mobile 5G == the idea of a >> > wearable /48 will really be many /48s. >> > >> > As this paradigm shift takes place, operators around the world >> will be >> > clamoring after the RIR for massive blocks, I would say less than /8 >> > more like a /5 or /4. If you do the math on the way high side a /10 >> > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR >> which is >> > tiny number with the number of large size operators worldwide. >> > >> > With the massive proliferation of IOT devices and just about >> every home >> > or office appliance on 5G, the problem now gets way exacerbated. >> > >> > As this evolution unfolds IANA will be scrambling to release all >> > remaining /3 as well as all unallocated blocks to subvert RIR IPv6 >> > address space depletion. >> > >> > Playing Monday night quarterbacking in hindsight we would never >> think >> > this would happen in a million years, but we would see IPv6 on >> the verge >> > of address space depletion. Unheard of but it can happen as the >> saying >> > goes “when you build - they will come”. >> > >> > It is true as history has taught that very important lesson. >> > >> > The answer to this real world problem is in the subject heading >> of this >> > thread. >> > >> > This would also fix the day 1 issue I mentioned allowing mix of >> slaac >> > devices with static and DHCPv6 up to /80. >> > >> > The variable slaac solution draft proposes a new RA PIO flag >> that would >> > be used to signal longer prefixes, and would provide backwards >> > compatibility so that devices not supporting woud ignore the flag >> and >> > devices on newer code supporting would use the flag. We definitely >> > don’t want to impact any existing devices on the existing 64 bit >> slaac >> > boundary standard. >> > >> > Dmytro has tested the solution on Linux kernel signaling RA PIO >> flag and >> > was able to successfully test any length mask and random IID >> generation >> > both RFC 4941 privacy extension as well as stable IID RFC 7217. >> > >> > >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ >> <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/> >> > >> <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ >> <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>> >> > >> > If everyone is in agreement with what I have stated on this >> thread, I >> > would like to ask the chairs for WG adoption as this is a WG effort. >> > >> > I would like to garner support from all 6MAN members with full >> consensus >> > to change the existing RFC 4941 /64 fixed boundary to /80 fixed >> boundary. >> > >> > Kind Regards >> > >> > Gyan >> > >> > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern >> <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> >> > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>> wrote: >> > >> > I am missing something in your reasoning. >> > You seem to say at one point that (to paraphrase) "we can't >> do this >> > because it does not work with the existing UE software". >> > Any new solution where a UE delegates based on any change of >> any kind >> > (including lengthening the prefix, shortening the prefix, or >> magically >> > incanting new prefixes) requires that the UE be upgraded to know >> > what to >> > do with the information. I do not see how that >> differentiates any of >> > the solutions. (Except "don't do anything", which I think we >> do not >> > want >> > to take.) >> > >> > Yours, >> > Joel >> > >> > On 11/19/2020 5:03 PM, Gyan Mishra wrote: >> > > >> > > >> > > On Thu, Nov 19, 2020 at 10:33 AM <otroan@employees.org >> <mailto:otroan@employees.org> >> > <mailto:otroan@employees.org <mailto:otroan@employees.org>> >> > > <mailto:otroan@employees.org <mailto:otroan@employees.org> >> <mailto:otroan@employees.org <mailto:otroan@employees.org>>>> wrote: >> > > >> > > >> > > >> > > > On 19 Nov 2020, at 14:58, Gyan Mishra >> > <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com> >> <mailto:hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>> >> > > <mailto:hayabusagsm@gmail.com >> <mailto:hayabusagsm@gmail.com> >> > <mailto: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 >> <https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=gmail&source=g> >> 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 p >> > >> <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g>>refixes >> > using RFC 4941 privacy >> > > extension or RFC 7217 stable IID. >> > > >> > > Win-Win for all. >> > > >> > > Ole >> > > >> > > -- >> > > >> > > <http://www.verizon.com/ <http://www.verizon.com/> >> <http://www.verizon.com/ <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 <mailto:v6ops@ietf.org> >> <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>> >> > > https://www.ietf.org/mailman/listinfo/v6ops >> <https://www.ietf.org/mailman/listinfo/v6ops> >> > <https://www.ietf.org/mailman/listinfo/v6ops >> <https://www.ietf.org/mailman/listinfo/v6ops>> >> > > >> > >> > -- >> > >> > <http://www.verizon.com/ <http://www.verizon.com/>> >> > >> > *Gyan Mishra* >> > >> > /Network Solutions A//rchitect / >> > >> > /M 301 502-1347 >> > 13101 Columbia Pike >> > /Silver Spring, MD >> > >> > >> >> -- >> >> <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 >
- The bottom is /112 (was: RE: Extending a /64) -- … Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… JORDI PALET MARTINEZ
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… otroan
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gert Doering
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Alexandre Petrescu
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… JORDI PALET MARTINEZ
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… JORDI PALET MARTINEZ
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… otroan
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Joel M. Halpern
- Re: [v6ops] The bottom is /112 Brian E Carpenter
- Re: [v6ops] The bottom is /112 Bob Hinden
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Ole Troan
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Joel M. Halpern
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Joel M. Halpern
- Next step? [Re: [v6ops] The bottom is /112] Brian E Carpenter
- Re: Next step? [Re: [v6ops] The bottom is /112] Mark Smith
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Mark Smith
- Re: [v6ops] Next step? [Re: The bottom is /112] Ca By
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gert Doering
- Re: [v6ops] Next step? [Re: The bottom is /112] Ole Troan
- Re: Next step? Alexandre Petrescu
- Re: Next step? [Re: [v6ops] The bottom is /112] Joel M. Halpern
- Re: Next step? [Re: [v6ops] The bottom is /112] Joel M. Halpern
- RE: [EXTERNAL] Re: [v6ops] Next step? [Re: The bo… Templin (US), Fred L
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [EXTERNAL] Re: [v6ops] Next step? [Re: The bo… Mark Smith
- Re: [v6ops] Next step? [Re: The bottom is /112] Michael Richardson
- Re: [v6ops] The bottom is /112 Gyan Mishra
- Re: [v6ops] The bottom is /112 Gyan Mishra
- RE: [v6ops] The bottom is /112 Pascal Thubert (pthubert)
- Re: [v6ops] The bottom is /112 Gert Doering
- Re: [v6ops] Next step? [Re: The bottom is /112] Templin (US), Fred L
- Re: [v6ops] The bottom is /112 Alexandre Petrescu
- RE: [v6ops] Next step? [Re: The bottom is /112] Templin (US), Fred L
- Re: [v6ops] The bottom is /112 Brian E Carpenter
- Re: [v6ops] The bottom is /112 Brian E Carpenter