Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso
Gyan Mishra <hayabusagsm@gmail.com> Sun, 22 November 2020 19:08 UTC
Return-Path: <hayabusagsm@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 0BC2C3A0ACB; Sun, 22 Nov 2020 11:08:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Gd3-Mk9zwVcr; Sun, 22 Nov 2020 11:08:12 -0800 (PST)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 2DA313A0AC6; Sun, 22 Nov 2020 11:08:12 -0800 (PST)
Received: by mail-pg1-x530.google.com with SMTP id 62so12162306pgg.12; Sun, 22 Nov 2020 11:08:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DL1f+ouz3h6WDmRx0FfMXts1NPYAWj0/+2f04GFm+ao=; b=EDfQfgOOSGc60BHpToqb7+f4Cp8lomYxZERaSIWavxTZuGU6PeWq+Fn2/5/7Hyz5y/ viiIdWWfWiFI/sNbjz1OATfRYFYBX8m9O0pyxO8N/kvp/f7Ce3g5YVVvY5hfcErqC3JY BY6DKS2nWakcCQ4CeB9CKp5vrhZj8FItLmIme7hcQZ6xHJpSH725jbvZFZfK/C0Garo9 YN2rYXStPWTJNJoQdj3s2sacWIs9jdZLQnVCxN5EUUPB8mdl9bQXlJ/sHiKO29RA6V1j sbR8w1Dv/scOKpTH7P47PQZgdaIJ6P3svsSjsUfi0fL4SERpP4S8QLujkXn5jw/h559n ZvgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DL1f+ouz3h6WDmRx0FfMXts1NPYAWj0/+2f04GFm+ao=; b=QpnyEMhTUGhOKhxMUQ6iH73gtQmX9Dbfb2gjjSElviuPsqfX9/7Ms1TfgNGSE/0IRY HzpV1uxSzHjowkstUgVXuA0x0uwJaMNVsVmFZxRSgdYQeeUlL+ZjihpOZrbNcw1IFGVS oDwe8mq5F0oYPT0BbRvLaFRy3WsgOdxtKThaiv9DQbGWrzobcoCMB+o9kziNqlpeB33r jBFj98PPZP1XxQRPcUf5L3z+18H6MQ7LZDPoandpnAVZ8qaU3/zJ8bFrYVqT/y6KYwz3 sGUNoHLp8Rw2NNjFUjYIfr9RzQoTVX/tzziocgerjbkWvYOmXkeEqKUtE/IAXZEaFx9Z kI4w==
X-Gm-Message-State: AOAM533J1dyixTItH9izzYyI78RF6B61a5P/yQ90ecR0NvgE+IDdrqr5 iUSAhihekT8y0NEqg+GTarpXItAu2j9nQDmLkU8=
X-Google-Smtp-Source: ABdhPJyGqLCtZa8zl6ksJc8f10tfE8Sk1B9nNrttLsEtS8giEQZgYJQ2+6Zi/snVM+Te/flzsAT9Ctt1At4ZXVpJCNM=
X-Received: by 2002:a17:90b:1490:: with SMTP id js16mr20938799pjb.215.1606072091502; Sun, 22 Nov 2020 11:08:11 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sun, 22 Nov 2020 14:08:00 -0500
Message-ID: <CABNhwV0BSrWKJMqxNL-W2VutZ-dFA8AgXa2Oz=fozyezSNODvQ@mail.gmail.com>
Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: 6MAN <6man@ietf.org>, IPv6 Operations <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007f6d3705b4b6cc1b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/s5sABsvQNAYuLTNaonFQ8uYzuSk>
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: Sun, 22 Nov 2020 19:08:16 -0000
On Fri, Nov 20, 2020 at 8:46 PM Joel M. Halpern <jmh@joelhalpern.com> wrote: > The nesting got me lost, so I will top post my take on the answer to the > one quesiton I could understand. Gyan> Thank you > > > 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. Gyan> Agreed > > > 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. Gyan> Agreed > > 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. Gyan>ok > > 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. Gyan> Yes Agreed. Thank you > > > Changing the prefix length to /80 is technically also possible. Gyan> > 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. Gyan> Understood. This is a multi faceted problem and may require a multi faceted solution. Thank you. > > > 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 > > > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
- 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