Re: IPv6 woes - RFC

> On Sep 30, 2021, at 19:35 , Victor Kuarsingh wrote: > > > > On Thu, Sep 30, 2021 at 10:01 PM Valdis Klētnieks > wrote: > On Wed, 29 Sep 2021 16:09:26 -0400, Victor Kuarsingh said: > > > - Both providers provide IPv6 and delegate a prefix to the router (let'

Re: IPv6 woes - RFC

On Thu, Sep 30, 2021 at 10:01 PM Valdis Klētnieks wrote: > On Wed, 29 Sep 2021 16:09:26 -0400, Victor Kuarsingh said: > > > - Both providers provide IPv6 and delegate a prefix to the router (let's > > pretend the retail staff knew enough to sell this person a consumer box > > with 2x WAN interfac

Re: IPv6 woes - RFC

On Wed, 29 Sep 2021 16:09:26 -0400, Victor Kuarsingh said: > - Both providers provide IPv6 and delegate a prefix to the router (let's > pretend the retail staff knew enough to sell this person a consumer box > with 2x WAN interfaces) So... do such boxes exist in any great quantity? Do consumers

Re: IPv6 woes - RFC

> On Sep 29, 2021, at 14:23 , Victor Kuarsingh wrote: > > > > On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas > wrote: > > > On 9/29/21 1:09 PM, Victor Kuarsingh wrote: >> >> >> On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong > > wrote: >> >> >>

Re: IPv6 woes - RFC

> On Sep 29, 2021, at 13:09 , Victor Kuarsingh wrote: > > > > On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong > wrote: > > >> On Sep 29, 2021, at 09:25, Victor Kuarsingh > > wrote: >> >>  >> >> >> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLon

Re: IPv6 woes - RFC

On Wed, Sep 29, 2021 at 5:49 PM Baldur Norddahl wrote: > > > On Wed, 29 Sept 2021 at 22:11, Victor Kuarsingh wrote: > >> In the consumer world (Where a consumer has no idea who we are, what IP >> is and the Internet is a wireless thing they attach to). >> >> I am only considering one router (con

Re: IPv6 woes - RFC

On Wed, 29 Sept 2021 at 22:11, Victor Kuarsingh wrote: > In the consumer world (Where a consumer has no idea who we are, what IP is > and the Internet is a wireless thing they attach to). > > I am only considering one router (consumer level stuff). Here is my > example: > I am afraid you are ta

Re: IPv6 woes - RFC

On 9/29/21 2:23 PM, Victor Kuarsingh wrote: On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas > wrote: On 9/29/21 1:09 PM, Victor Kuarsingh wrote: On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong mailto:o...@delong.com>> wrote: On Sep 29, 2021, at 09:25,

Re: IPv6 woes - RFC

On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas wrote: > > On 9/29/21 1:09 PM, Victor Kuarsingh wrote: > > > > On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong wrote: > >> >> >> On Sep 29, 2021, at 09:25, Victor Kuarsingh wrote: >> >>  >> >> >> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG

Re: IPv6 woes - RFC

On 9/29/21 1:09 PM, Victor Kuarsingh wrote: On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong > wrote: On Sep 29, 2021, at 09:25, Victor Kuarsingh mailto:vic...@jvknet.com>> wrote:  On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG mailto:nanog@n

Re: IPv6 woes - RFC

ently dual homed, having 2 uplinks, RFC1918 LAN, doing policy >>> routing and NATing however I want.. >>> >>> >> why of COURSE you do source address selection! >> so simple! >> >> >>> >>> -- Original message -

Re: IPv6 woes - RFC

On 9/29/21 12:22 PM, Owen DeLong via NANOG wrote: On Sep 29, 2021, at 09:25, Victor Kuarsingh wrote:  On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG mailto:nanog@nanog.org>> wrote: Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set

Re: IPv6 woes - RFC

cy >>>> routing and NATing however I want.. >>>> >>> >>> why of COURSE you do source address selection! >>> so simple! >>> >>>> >>>> -- Original message -- >>>> >>>> From: M

Re: IPv6 woes - RFC

d NATing however I want.. >> >> > why of COURSE you do source address selection! > so simple! > > >> >> ------ Original message -- >> >> From: Mark Andrews >> To: b...@uu3.net >> Cc: nanog@nanog.org >> Subject: Re: IPv6 wo

Re: IPv6 woes - RFC

hy of COURSE you do source address selection! > so simple! > >> >> -- Original message -- >> >> From: Mark Andrews >> To: b...@uu3.net >> Cc: nanog@nanog.org >> Subject: Re: IPv6 woes - RFC >> Date: Wed, 29 Sep 2021 00:28:40

Re: IPv6 woes - RFC

lection! so simple! > > -- Original message -- > > From: Mark Andrews > To: b...@uu3.net > Cc: nanog@nanog.org > Subject: Re: IPv6 woes - RFC > Date: Wed, 29 Sep 2021 00:28:40 +1000 > > > > > On 28 Sep 2021, at 19:19, b...@uu3.net wrote: > > > >

Re: IPv6 woes - RFC

On Tue, Sep 28, 2021 at 4:18 PM Randy Bush wrote: > >> the ietf did not give guidance to cpe vendors to protect toys inside > >> your LAN > > guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) is > > likely to impact all of our security 'requirements'. :( > > that point was ma

Re: IPv6 woes - RFC

> list of how cool IPv6 is and how everyone should use it right away. > > > ------ Original message -- > > From: Owen DeLong > To: b...@uu3.net > Cc: nanog@nanog.org > Subject: Re: IPv6 woes - RFC > Date: Sat, 25 Sep 2021 12:01:22 -0700 > > > &

Re: IPv6 woes - RFC

On Tue, 28 Sept 2021 at 22:05, Randy Bush wrote: > https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf > > the ietf did not give guidance to cpe vendors to protect toys inside > your LAN Luckily Amazon, Google, Apple, et.al. want to sell us products, and they noticed lac

Re: IPv6 woes - RFC

On Tue, Sep 28, 2021 at 10:25 PM Randy Bush wrote: > > https://datatracker.ietf.org/doc/html/rfc6092 > > good stuff. thanks. > The memories are all coming back now. I thought this was old news. regards, Victor K

Re: IPv6 woes - RFC

> https://datatracker.ietf.org/doc/html/rfc6092 good stuff. thanks.

Re: IPv6 woes - RFC

> On 29 Sep 2021, at 05:02, Randy Bush wrote: > >> Heh, NAT is not that evil after all. Do you expect that all the home >> people will get routable public IPs for all they toys inside house? > > in ipv6 they can. and it can have consequences, see > >NATting Else Matters: Evaluating IPv6

Re: IPv6 woes - RFC

>> the ietf did not give guidance to cpe vendors to protect toys inside >> your LAN > guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) is > likely to impact all of our security 'requirements'. :( that point was made in the paper i cited > I also thought 'homenet' (https://da

Re: IPv6 woes - RFC

On 9/28/21 1:06 PM, Christopher Morrow wrote: On Tue, Sep 28, 2021 at 3:02 PM Randy Bush > wrote: > Heh, NAT is not that evil after all. Do you expect that all the home > people will get routable public IPs for all they toys inside house? in ipv6 they can. 

Re: IPv6 woes - RFC

On Tue, Sep 28, 2021 at 3:02 PM Randy Bush wrote: > > Heh, NAT is not that evil after all. Do you expect that all the home > > people will get routable public IPs for all they toys inside house? > > in ipv6 they can. and it can have consequences, see > > NATting Else Matters: Evaluating IPv6

Re: IPv6 woes - RFC

> Heh, NAT is not that evil after all. Do you expect that all the home > people will get routable public IPs for all they toys inside house? in ipv6 they can. and it can have consequences, see NATting Else Matters: Evaluating IPv6 Access Control Policies in Residential Networks; Kar

Re: IPv6 woes - RFC

> On Sep 28, 2021, at 08:13 , Masataka Ohta > wrote: > > Mark Andrews wrote: > >>> Heh, NAT is not that evil after all. Do you expect that all the home >>> people will get routable public IPs for all they toys inside house? >> Yes! Remember routable does not mean that it is reachable from ou

Re: IPv6 woes - RFC

the recognition that IPv4 is a dead end whether people want to admit it or not. Owen > > > -- Original message ------ > > From: Owen DeLong > To: b...@uu3.net > Cc: nanog@nanog.org > Subject: Re: IPv6 woes - RFC > Date: Sat, 25 Sep 2021 12:01:22 -0700 >

Re: IPv6 woes - RFC

Mark Andrews wrote: Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house? Yes! Remember routable does not mean that it is reachable from outside. Do you mean, because of hole punching, "not routable" does not

Re: IPv6 woes - RFC

yone should use it right away. > > > ------ Original message -- > > From: Owen DeLong > To: b...@uu3.net > Cc: nanog@nanog.org > Subject: Re: IPv6 woes - RFC > Date: Sat, 25 Sep 2021 12:01:22 -0700 > > > >> On Sep 25, 2021, at 01:57 ,

Re: IPv6 woes - RFC

b...@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Sat, 25 Sep 2021 12:01:22 -0700 > On Sep 25, 2021, at 01:57 , b...@uu3.net wrote: > > Well, I think we should not compare IPX to IPv4 because those protocols > were made to handle completly different networks? &g

Re: IPv6 woes - RFC

On Saturday, September 25, 2021 21:55 Chris Adams wrote: > More than once, I've had to explain why zero-filling octets, like > 127.000.000.001 (which still works) or 008.008.008.008 (which does not), > is broken. Zero filling IPv4 is just evil. How about this party trick? > % ping -c 1 010.010

Re: IPv6 woes - RFC

Originally, textual IPv4 addresses were maintained centrally by ISI as a file format of HOSTS.TXT, when there was no DNS and users are required to download the current most HOSTS.TXT from ISI through ftp. At that time, there can be, because of consistent central management, just one way to repres

Re: IPv6 woes - RFC

Valdis Klētnieks wrote on 26/09/2021 01:44: 19:17:38 0 [~] ping 2130706433 PING 2130706433 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.126 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.063 ms

Re: IPv6 woes - RFC

Once upon a time, Andy Smith said: > On Sat, Sep 25, 2021 at 08:44:00PM -0400, Valdis Klētnieks wrote: > > 19:17:38 0 [~] ping 2130706433 > > "ping 01770001" and "ping 0x7F01" also fun ones :) More than once, I've had to explain why zero-filling octets, like 127.000.000.001 (which still

Re: IPv6 woes - RFC

Hello, On Sat, Sep 25, 2021 at 08:44:00PM -0400, Valdis Klētnieks wrote: > 19:17:38 0 [~] ping 2130706433 "ping 01770001" and "ping 0x7F01" also fun ones :) Cheers, Andy

Re: IPv6 woes - RFC

On Sep 25, 2021, at 8:44 PM, Valdis Klētnieks wrote: > > On Sat, 25 Sep 2021 23:20:26 +0200, Baldur Norddahl said: > >> We should remember there are also multiple ways to print IPv4 addresses. >> You can zero extend the addresses and on some ancient systems you could >> also use the integer valu

Re: IPv6 woes - RFC

On Sat, 25 Sep 2021 23:20:26 +0200, Baldur Norddahl said: > We should remember there are also multiple ways to print IPv4 addresses. > You can zero extend the addresses and on some ancient systems you could > also use the integer value. 19:17:38 0 [~] ping 2130706433 PING 2130706433 (127.0.0.1) 5

Re: IPv6 woes - RFC

> On Sep 25, 2021, at 14:20 , Baldur Norddahl wrote: > > > > On Sat, 25 Sept 2021 at 21:26, Owen DeLong via NANOG > wrote: > So the fact that: > > 2001:db8:0:1::5 > 2001:db8::1:0:0:0:5 > > Are two different ways of representing the same address isn’t

Re: IPv6 woes - RFC

On Sat, 25 Sept 2021 at 21:26, Owen DeLong via NANOG wrote: > So the fact that: > > 2001:db8:0:1::5 > 2001:db8::1:0:0:0:5 > > Are two different ways of representing the same address isn’t > of any concern unless you’re making the mistake of trying to > string wise compare them in

Re: IPv6 woes - RFC

> On Sep 25, 2021, at 02:10 , b...@uu3.net wrote: > > Because IPv4 loopback is 127.0.0.1/8 and its usefull? How so? Where do you actually use 16.7 million loopback addresses, let alone 18 Quitillion+ * 65536 (/48)? > > 0:0:1-:0/32 means you generate addreses from > that range and not nec

Re: IPv6 woes - RFC

y factually incorrect. For the last category, I presume that comes from your lack of actual IPv6 experience or some other form of ignorance and I’d like to attempt useful education to address those. Owen > > > ------ Original message -- > > From: Grant Taylor via NANOG

Re: IPv6 woes - RFC

On Sat, 25 Sept 2021 at 11:10, wrote: > Because IPv4 loopback is 127.0.0.1/8 and its usefull? > I am not sure why it is useful but nothing stops you from adding more loopback addresses: root@jump2:~# ip addr add ::2/128 dev lo root@jump2:~# ping6 ::2 PING ::2(::2) 56 data bytes 64 bytes from ::

Re: IPv6 woes - RFC

ld be 1997 again... ;) -- Original message -- From: Owen DeLong To: b...@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 17:24:29 -0700 > On Sep 24, 2021, at 2:01 AM, b...@uu3.net wrote: > > Oh yeah, it would be very funny if this will

Re: IPv6 woes - RFC

defend my standpoint here. Its too late for that. I kinda regret now dropping into discussion... -- Original message -- From: Grant Taylor via NANOG To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 14:26:27 -0600 On 9/24/21 11:53 AM, b...@uu3.net wrote

Re: IPv6 woes - RFC

ent to how content providers react to this situation over the next few years. Owen > > > -- Original message -- > > From: Grant Taylor via NANOG > To: nanog@nanog.org > Subject: Re: IPv6 woes - RFC > Date: Fri, 24 Sep 2021 10:17:42 -0600 > > On 9/24/21 3

Re: IPv6 woes - RFC

> On Sep 24, 2021, at 9:56 AM, Joe Maimon wrote: > > > > Owen DeLong wrote: >> >>> On Sep 23, 2021, at 13:26 , Joe Maimon wrote: >>> >>> >>> I hope not, both for IPv6 sake and for the network users. We dont know how >>> much longer the goal will take, there is materializing a real possi

Re: IPv6 woes - RFC

concept), so its easy to implement and less > prone to bugs. > > And that IPv6 I would love to see and addapt right away :) Well.. Present your working prototype on at least two different systems. ;-) Owen > > > -- Original message -- > > From: Joe M

Re: IPv6 woes - RFC

b...@uu3.net wrote: Well, I see IPv6 as double failure really. First, IPv6 itself is too different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine. IPv4 was extendable, with header o

Re: IPv6 woes - RFC

On 9/24/21 11:53 AM, b...@uu3.net wrote: Well, I see IPv6 as double failure really. I still feel like you are combining / conflating two distinct issues into one generalization. First, IPv6 itself is too different from IPv4. Is it? Is it really? Is the delta between IPv4 and IPv6 greate

Re: IPv6 woes - RFC

On 9/24/21 10:53 AM, b...@uu3.net wrote: Well, I see IPv6 as double failure really. First, IPv6 itself is too different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine. It should just

Re: IPv6 woes - RFC

. -- Original message -- From: Grant Taylor via NANOG To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 10:17:42 -0600 On 9/24/21 3:01 AM, b...@uu3.net wrote: > Oh yeah, it would be very funny if this will really happen (new protocol). > Im not happy with IPv6, and it

Re: IPv6 woes - RFC

Owen DeLong wrote: On Sep 23, 2021, at 13:26 , Joe Maimon wrote: I hope not, both for IPv6 sake and for the network users. We dont know how much longer the goal will take, there is materializing a real possibility we will never quite reach it, and the potholes on the way are pretty roug

Re: IPv6 woes - RFC

On 9/24/21 3:01 AM, b...@uu3.net wrote: Oh yeah, it would be very funny if this will really happen (new protocol). Im not happy with IPv6, and it seems many others too. Is your dissatisfaction with the IPv6 protocol itself or is your dissatisfaction with the deployment / adoption of the IPv6 p

Re: IPv6 woes - RFC

nal message -- From: Joe Maimon To: Owen DeLong , Bjrn Mork Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Thu, 23 Sep 2021 16:26:17 -0400 Owen DeLong via NANOG wrote: > > There are real issues with dual-stack, as this thread started out with. > > I don't think the

Re: IPv6 woes - RFC

> On Sep 23, 2021, at 18:48 , Brian Johnson wrote: > > > >> On Sep 23, 2021, at 6:49 PM, Owen DeLong wrote: >> >> >> >>> On Sep 23, 2021, at 12:50 , Brian Johnson wrote: >>> >>> Side question on this thread… >>> >>> Is it everyones current expectation that if a provider were to switch

Re: IPv6 woes - RFC

It appears that Brian Johnson said: >Side question on this thread… > >Is it everyones current expectation that if a provider were to switch to IPv6 >and drop IPv4 that the customers would all be >just fine with that? Try sending e-mail to AOL/Yahoo or Hotmail/Outlook over IPv6. R's, John

Re: IPv6 woes - RFC

On Thu, Sep 23, 2021 at 4:13 PM Baldur Norddahl wrote: > > > On Thu, 23 Sept 2021 at 21:48, Christopher Morrow > wrote: > >> This sounds like very naive nat state management behavior. >> Ideally, you'd be able to maintain state of: >> original-src/dst/ports/proto -> in-interface/external ip/por

Re: IPv6 woes - RFC

> On Sep 23, 2021, at 6:49 PM, Owen DeLong wrote: > > > >> On Sep 23, 2021, at 12:50 , Brian Johnson wrote: >> >> Side question on this thread… >> >> Is it everyones current expectation that if a provider were to switch to >> IPv6 and drop IPv4 that the customers would all be just fine w

Re: IPv6 woes - RFC

> On Sep 23, 2021, at 13:26 , Joe Maimon wrote: > > > > Owen DeLong via NANOG wrote: >>> There are real issues with dual-stack, as this thread started out with. >>> I don't think there is a need neither to invent IPv6 problems, nor to >>> promote IPv6 advantages. What we need is a way out o

Re: IPv6 woes - RFC

> On Sep 23, 2021, at 12:50 , Brian Johnson wrote: > > Side question on this thread… > > Is it everyones current expectation that if a provider were to switch to IPv6 > and drop IPv4 that the customers would all be just fine with that? I believe > that there are several applications used by

Re: IPv6 woes - RFC

So a single level of NAT and a similar level of customers to that which was stated could be supported by a single IP. This is not quite a apples to apples comparison to the double NAT scenario being described below but close enough for the number of sessions. Mark > On 24 Sep 2021, at 01:34, Col

Re: IPv6 woes - RFC

Owen DeLong via NANOG wrote: There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell. I don’t disagree, but a reversion to IPv4-only cer

Re: IPv6 woes - RFC

The DMCA notices for that single ipv4 /32 must be interesting. On Thu, Sep 23, 2021 at 11:35 AM Colton Conor wrote: > 300 apartments Mark. No, it's bulk internet and wifi so a single provider. > > On Wed, Sep 22, 2021 at 8:01 PM Mark Andrews wrote: > > > > And how many apartments where covered

Re: IPv6 woes - RFC

On Thu, 23 Sept 2021 at 21:48, Christopher Morrow wrote: > This sounds like very naive nat state management behavior. > Ideally, you'd be able to maintain state of: > original-src/dst/ports/proto -> in-interface/external ip/port/proto > What you describe is called symmetric NAT and is the kind

Re: IPv6 woes - RFC

Side question on this thread… Is it everyones current expectation that if a provider were to switch to IPv6 and drop IPv4 that the customers would all be just fine with that? I believe that there are several applications used by some of the the loudest customers (typically gamers and network gu

Re: IPv6 woes - RFC

On Thu, Sep 23, 2021 at 3:42 AM Baldur Norddahl wrote: > > > tor. 23. sep. 2021 01.39 skrev Colton Conor : > >> Where does this "You can only have about 200-300 subscribers per IPv4 >> address on a CGN." limit come from? I have seen several apartment >> complexes run on a single static IPv4 addre

Re: IPv6 woes - RFC

> There are real issues with dual-stack, as this thread started out with. > I don't think there is a need neither to invent IPv6 problems, nor to > promote IPv6 advantages. What we need is a way out of dual-stack-hell. I don’t disagree, but a reversion to IPv4-only certainly won’t do it. I think

Re: IPv6 woes - RFC

300 apartments Mark. No, it's bulk internet and wifi so a single provider. On Wed, Sep 22, 2021 at 8:01 PM Mark Andrews wrote: > > And how many apartments where covered by that single IP address? Was this > where there is a restriction on other providers so the occupants had no > choice of wireli

Re: IPv6 woes - RFC

Masataka Ohta writes: > That IPv6 will be disaggregated into /40 or even /32 is disastrous. It won't. No ISPs will deaggregate anything. Some multi-site enterprises might assign a /48 per remote site from their single prefix, and want those /48s routed via some transit peers. But this does not

Re: IPv6 woes - RFC

tor. 23. sep. 2021 01.39 skrev Colton Conor : > Where does this "You can only have about 200-300 subscribers per IPv4 > address on a CGN." limit come from? I have seen several apartment > complexes run on a single static IPv4 address using a Mikrotik with > NAT. > It is our observation as the lim

Re: IPv6 woes - RFC

> On Sep 22, 2021, at 07:47 , Masataka Ohta > wrote: > > Owen DeLong wrote: > >>> As mergers of ASes increases the number of announcements and IPv4 >>> addresses were allocated a lot earlier than those of IPv6, >>> comparing the current numbers of announcements is not meaningful. >> Mergers

Re: IPv6 woes - RFC

And how many apartments where covered by that single IP address? Was this where there is a restriction on other providers so the occupants had no choice of wireline ISP? > On 23 Sep 2021, at 09:38, Colton Conor wrote: > > Where does this "You can only have about 200-300 subscribers per IPv4 > ad

Re: IPv6 woes - RFC

Where does this "You can only have about 200-300 subscribers per IPv4 address on a CGN." limit come from? I have seen several apartment complexes run on a single static IPv4 address using a Mikrotik with NAT. On Wed, Sep 22, 2021 at 2:49 PM Baldur Norddahl wrote: > > > > On Wed, 22 Sept 2021 at 1

Re: IPv6 woes - RFC

On Wed, 22 Sept 2021 at 16:48, Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > Today, as /24 can afford hundreds of thousands of subscribers > by NAT, only very large retail ISPs need more than one > announcement for IPv4. > You can only have about 200-300 subscribers per IPv4 address

Re: IPv6 woes - RFC

On 2021-09-19 09:20, Masataka Ohta wrote: John Levine wrote: Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai. I wasn't talking about switches

Re: IPv6 woes - RFC

Owen DeLong wrote: As mergers of ASes increases the number of announcements and IPv4 addresses were allocated a lot earlier than those of IPv6, comparing the current numbers of announcements is not meaningful. Mergers of ASes does not increase announcements in IPv4 nearly as much as slow-start

Re: IPv6 woes - RFC

> On Sep 20, 2021, at 06:48 , Brian Turnbow via NANOG wrote: > > Hi, > >>> v4 is so thoroughly fragmented and v6 is a lot less likely to become >>> so. >> >> It is true that fragmentation is a problem. However, it merely means that >> IPv6 >> address space will also be fragmented and that >

Re: IPv6 woes - RFC

> On Sep 20, 2021, at 05:15 , Masataka Ohta > wrote: > > Owen DeLong wrote: > >>> But, on routers, IPv6 costs four times more than IPv4 to look up >>> routing table with TCAM or Patricia tree. >>> It is not a problem yet, merely because full routing table of IPv6 >>> is a lot smaller than th

Re: IPv6 woes - RFC

> On Sep 19, 2021, at 16:17 , Victor Kuarsingh wrote: > > Owen, > > > On Sat, Sep 18, 2021 at 23:51 Owen DeLong > wrote: >> On Sep 18, 2021, at 12:34 , Victor Kuarsingh > > wrote: >> >> On Sat, Sep 18, 2021 at 2:39 PM John Levine >

RE: IPv6 woes - RFC

Hi, > > v4 is so thoroughly fragmented and v6 is a lot less likely to become > > so. > > It is true that fragmentation is a problem. However, it merely means that IPv6 > address space will also be fragmented and that > IPv4 can but IPv6 can't be deployed at full scale, Just this week We had our

Re: IPv6 woes - RFC

Owen DeLong wrote: But, on routers, IPv6 costs four times more than IPv4 to look up routing table with TCAM or Patricia tree. It is not a problem yet, merely because full routing table of IPv6 is a lot smaller than that of IPv4, which means most small ISPs and multihomed sites do not support IP

Re: IPv6 woes - RFC

It appears that Stephen Satchell said: >> or get an HE /48 over a tunnel which will do PTR or NS records appropriately. > >Hurricane Electric? Seriously? I've been using HE's free ipv6 tunnels for ten years. They work great. I don't ever recall any downtime. They assign you a /64 by default, /48

Re: IPv6 woes - RFC

Owen, On Sat, Sep 18, 2021 at 23:51 Owen DeLong wrote: > On Sep 18, 2021, at 12:34 , Victor Kuarsingh wrote: > > On Sat, Sep 18, 2021 at 2:39 PM John Levine wrote: > >> It appears that Owen DeLong via NANOG said: >> >> > Glad you noted this. Thinking this was/is purely a hardware cycle prob

Re: IPv6 woes - RFC

> On Sep 10, 2021, at 00:21 , Bjørn Mork wrote: > > Owen DeLong via NANOG writes: > >> The addresses aren’t the major cost of providing IPv4 services. >> >> CGN boxes, support calls, increasing size of routing table = buying new >> routers, etc. > > You're counting dual-stack costs as if

Re: IPv6 woes - RFC

> On Sep 18, 2021, at 23:20 , Masataka Ohta > wrote: > > John Levine wrote: > >>> Unless their infrastructure runs significantly on hardware and >>> software pre-2004 (unlikely), so does the cost of adding IPv6 to >>> their content servers. Especially if they’re using a CDN such as >>> Akama

Re: IPv6 woes - RFC

Saku Ytti wrote: It is almost guaranteed we are married to IPv4 past our life cycles, because there will be a lot of drivers to keep it. So, the war was between "IPv4 with NAT" and "IPv4 dual stacked with IPv6". If IPv6 were simple, quickly standardized and easily deployable, which are technic

Re: IPv6 woes - RFC

On 9/18/21 11:20 PM, Masataka Ohta wrote: Mark Andrews wrote: > There is nothing at the protocol level stopping AT&T offering a > similar level of service. Setting up reverse DNS lookup for 16B address is annoying, which may stop AT&T offering it. How many mail servers are on the Internet t

Re: IPv6 woes - RFC

People who keep thinking this is a technical problem that can be engineered away are confused. People who think the relative cost of doing lookup for IPV4/IPV6 is visible to TCO are confused. Just because you can observe technical differences doesn't mean they are important, it may mean you're bein

Re: IPv6 woes - RFC

John Levine wrote: Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai. I wasn't talking about switches and routers. But, on routers, IPv6 costs

Re: IPv6 woes - RFC

On 9/18/21 8:58 PM, Owen DeLong wrote: I haven’t tried the PTR thing yet, but I do have a small business client that has AT&T business internet and they were able to get a static /56 (For some reason, AT&T refused to do a /48, but we did push them on it.) When I checked, there were NO options

Re: IPv6 woes - RFC

I haven’t tried the PTR thing yet, but I do have a small business client that has AT&T business internet and they were able to get a static /56 (For some reason, AT&T refused to do a /48, but we did push them on it.) If it turns out they won’t do PTR or more likely NS for our ip6.arpa zone, then

Re: IPv6 woes - RFC

> On Sep 18, 2021, at 13:25 , John R. Levine wrote: > >> As you noted John, its the plethora of software, support systems, tooling, >> and most important in many environments - legacy customer management and >> provisioning systems that can be the limiting factor. ... > > Just looking around

Re: IPv6 woes - RFC

> On Sep 18, 2021, at 12:34 , Victor Kuarsingh wrote: > > > > On Sat, Sep 18, 2021 at 2:39 PM John Levine > wrote: > It appears that Owen DeLong via NANOG > said: > >> The cost of putting flyers in the bills rounds to zero, so yes, really. I >

Re: IPv6 woes - RFC

> On Sep 18, 2021, at 11:37 , John Levine wrote: > > It appears that Owen DeLong via NANOG said: >>> The cost of putting flyers in the bills rounds to zero, so yes, really. I >>> expect these companies all have plans >> to support v6 eventually, someday, once they're retired and replaced all

Re: IPv6 woes - RFC

According to Mark Andrews : >It tells you that AT&T don’t treat IPv6 on equal footing to IPv4 and nothing >more. Indeed but since AT&T is about 1/4 of the US broadband market, and our screwed up telco politics means there is often no practical competitor available, that's a big problem. R's,

Re: IPv6 woes - RFC

It tells you that AT&T don’t treat IPv6 on equal footing to IPv4 and nothing more. There is nothing at the protocol level stopping AT&T offering a similar level of service. Don’t equate poor implementation with the protocol being broken. -- Mark Andrews > On 19 Sep 2021, at 07:19, Stephen Sat

Re: IPv6 woes - RFC

Also, I realise I'm kinda taking your comment out of context and jumping on it to harp on my favorite pet peeve, so, yeah, sorry about that. --TimH On Sat, 18 Sep 2021 13:28:02 -0700 Tim Howe wrote: > On Fri, 17 Sep 2021 21:15:00 -0700 > Owen DeLong via NANOG wrote: > > > Unless their infrast

Re: IPv6 woes - RFC

I mostly agree with this. Even new hardware like eero doesn't do v6 by default. It's just off. So many things are like this. It's nice that LTE and other deployments have v6 by default. Last time I knew providers like t mobile are great but their MVNOs like Ultra Mobile do not do v6. All this

Re: IPv6 woes - RFC

I concur that the problem is not a routing hardware problem. It's a perception problem with the various ISPs. I have fiber service with AT&T. My little server farm endpoints all have IPv6 addresses, including the edge router. I also have a plan to allocate IPv6 addresses to my LAN devices,

  1   2   3   >