Owen DeLong wrote:
Again, wrong. The number is growing exponentially primarily
because of the fragmentation that comes from recycling
addresses.
Nope… It occurs when (e.g. HP or MIT or AMPR) sell off pieces of a
class A as smaller prefixes to various other purchasers.
That, by no means, is
Dave Taht wrote:
The proper solution is to have end to end multihoming:
https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt
I'd never read that. We'd made openwrt in particular use "source
specific routing" for ipv6 by default,
many years ago, but I don't know to what extent
On 23/11/2021 22:31, Chuck Church wrote:
Old issue. Everyone encounters this at some point:
https://www.iucc.ac.il/en/blog/2021-05-google-geo-location/
You can try reporting it to Google:
https://support.google.com/websearch/workflow/9308722?hl=en
and wait a month or so to see if the issue gets
On Tue, Nov 23, 2021 at 9:02 PM David Conrad wrote:
> On Nov 23, 2021, at 10:33 AM, William Herrin wrote:
> > 1. Move it from "reserved" to "unallocated unicast" (IETF action)
>
> Or…
>
> 1. IAB or IESG requests the IANA team to delegate one of
> the 240/4 /8s to the RIRs on demand for experiment
On Nov 23, 2021, at 10:33 AM, William Herrin wrote:
> On Tue, Nov 23, 2021 at 5:03 AM Eliot Lear wrote:
>> So what's the road to actually being able to use [240/4]?
>
> 1. Move it from "reserved" to "unallocated unicast" (IETF action)
> 2. Wait 10 years
> 3. Now that nearly all equipment that d
When considering the IPv6 product, I would suggest you read
USGv6-Revision-1 (1) to define the specification you need for the product.
Then go to the USGv6 Registry (2), select the features and read the
Supplier Declaration of Conformity (SDOC) to ensure that the product meets
your requirements. Do
It appears that Francis Booth via NANOG said:
>So we know RFC 2606 defined reserved TLDs like .lan and .home so there
Um, this must be a different RFC 2606 than the one the rest of us have read.
It mentions neither .lan nor .home.
>In order to solve the chicken/egg problem of having to know your
> On Nov 23, 2021, at 12:28 AM, Masataka Ohta
> wrote:
>
> Owen DeLong wrote:
>
>>> The number of routing table entries is growing exponentially, not
>>> because of increase of the number of ISPs, but because of multihoming.
>> Again, wrong. The number is growing exponentially primarily becau
NANOG,
Sorry if this is the wrong forum, but I figured we could all
use a distraction from IPV4 expansion for a bit. We're facing a problem
with corporate use of browsers and google location services. Our users
across North and South America seem to be getting location info fo
> On Nov 20, 2021, at 6:35 PM, Matthew Walster wrote:
>
> I genuinely believe we're reaching a stalling point for IPv6 service
> enabling, and it's time to focus energy on running IPv6 only clients -- and
> to do that, we need to make the IPv6 only experience for residential / soho
> be as p
On Tue, Nov 23, 2021 at 5:03 AM Eliot Lear wrote:
> So what's the road to actually being able to use [240/4]?
1. Move it from "reserved" to "unallocated unicast" (IETF action)
2. Wait 10 years
3. Now that nearly all equipment that didn't treat it as
yet-to-be-allocated unicast has cycled out of u
On Mon, Nov 22, 2021 at 2:49 AM Masataka Ohta
wrote:
>
> Mans Nilsson wrote:
>
> > Not everyone are Apple, "hp"[0] or MIT, where initial
> > allocation still is mostly sufficient.
>
> The number of routing table entries is growing exponentially,
> not because of increase of the number of ISPs, b
Greg
Thanks for posting the links. Our old draft seems to have largely had
its intended effect without ever having been issued as an RFC
(moohaha). Most implementations don't hardcode 240/4 into a bogon
filter. We had at the time left open what next steps should be.
So what's the road to
Owen DeLong wrote:
The number of routing table entries is growing exponentially, not
because of increase of the number of ISPs, but because of
multihoming.
Again, wrong. The number is growing exponentially primarily because
of the fragmentation that comes from recycling addresses.
Such frag
14 matches
Mail list logo
