Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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's
> > pretend the retail staff knew enough to sell this person a consumer box
> > with 2x WAN interfaces)
> 
> Just to make it clear, I would love it all to work really well and by 
> default.  But I also look at the reality and don't over estimate how 
> proficient consumers will be.

No reason it can’t. The limitations on this are not in the protocol or the 
specifications at this point. CPE is another matter. It’s never been 
particularly good at IPv4, let alone IPv6.

> So... do such boxes exist in any great quantity?
> 
> Not in great quantity.  But for the fun of it, I ran down to the local 
> BestBuy recently and they offered me a dual WAN router (only one type) in 
> stock.  So, I guess sufficient supply?

How well did it handle IPv6?

> Do consumers who can't add a valid number after 'IPv' accidentally contract 
> for
> Internet service from two different providers often? Do they intentionally do
> that often?
> 
> Likely not accidentally, but the router they showed me (will not say what 
> brand on this list) showed a "WAN" and "WAN/DMZ" port, so just as clear as 
> any other port markings for consumer grade connections.  

I’m an expert and that’s not clear to me. Which one is primary, which one is 
secondary?

Does that second notation mean WAN and DMZ, or does it mean WAN OR DMZ?

WAN+DMZ on same port seems an odd combination. OTOH, “OR” would imply a need to 
configure it one way or the other and for the consumer to understand the 
concept of a DMZ network and…

> It sounds like a sufficiently rare situation that "clueless lawyer/whatever
> hires somebody with clue for 2 hours work to configure it all" is a reasonable
> solution.
> 
> Yes, I suspect that may happen. How many clueful IPv6 folks do we suspect 
> service this market which are available at a cost most will be willing to pay?

$LAWYER won’ t blink at paying $250/hour for 2 hours of work to configure a 
router. I’ve done so for several of them.

They also don’t blink at billing their clients much more than that per hour.

Owen

Re: IPv6 woes - RFC

[Victor Kuarsingh]

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 interfaces)
>

Just to make it clear, I would love it all to work really well and by
default.  But I also look at the reality and don't over estimate how
proficient consumers will be.


>
> So... do such boxes exist in any great quantity?
>

Not in great quantity.  But for the fun of it, I ran down to the local
BestBuy recently and they offered me a dual WAN router (only one type) in
stock.  So, I guess sufficient supply?


>
> Do consumers who can't add a valid number after 'IPv' accidentally
> contract for
> Internet service from two different providers often? Do they intentionally
> do
> that often?
>

Likely not accidentally, but the router they showed me (will not say what
brand on this list) showed a "WAN" and "WAN/DMZ" port, so just as clear as
any other port markings for consumer grade connections.


>
> It sounds like a sufficiently rare situation that "clueless lawyer/whatever
> hires somebody with clue for 2 hours work to configure it all" is a
> reasonable
> solution.
>

Yes, I suspect that may happen. How many clueful IPv6 folks do we suspect
service this market which are available at a cost most will be willing to
pay?

regards,

Victor K

Re: IPv6 woes - RFC

[Valdis Klētnieks]

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 who can't add a valid number after 'IPv' accidentally contract for
Internet service from two different providers often? Do they intentionally do
that often?

It sounds like a sufficiently rare situation that "clueless lawyer/whatever
hires somebody with clue for 2 hours work to configure it all" is a reasonable
solution.



pgpTz8s7miAkD.pgp
Description: PGP signature

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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:
>> 
>> 
>>> On Sep 29, 2021, at 09:25, Victor Kuarsingh >> > wrote:
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG >> > wrote:
>>> Use SLAAC, allocate prefixes from both providers. If you are using multiple 
>>> routers, set the priority of the preferred router to high in the RAs. If 
>>> you’re using one router, set the preferred prefix as desired in the RAs. 
>>> 
>>> Owen
>>> 
>>> I agree this works, but I assume that we would not consider this a consumer 
>>> level solution (requires an administrator to make it work).  It also 
>>> assumes the local network policy allows for auto-addressing vs. requirement 
>>> for DHCP.  
>> 
>> It shouldn’t require an administrator if there’s just one router. If there 
>> are two routers, I’d say we’re beyond the average consumer. 
>> 
>> 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:
>> - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a 
>> local cable service and/or DSL service, and/or xPON service
>> 
> Isn't the easier (and cheaper) thing to do here is just use a VPN to get 
> behind the corpro firewall? Or as is probably happening more and more there 
> is no corpro network at all since everything is outsourced on the net for 
> smaller companies like your law firm.
> 
> 
> For shops with IT departments, sure that can make sense.  For many mom/pop 
> setups, maybe less likely.  The challenge for us (in this industry) is that 
> we need to address not just the top use cases, but the long tail as well 
> (especially in this new climate of more WFH).

The mom/pop law firm without an IT department probably isn’t working from home 
any more, they’re probably back in the office.

In any case, they probably have the office “resources” they want to use for WFH 
in the cloud somewhere so there’s no difference
in access between home and office.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 DeLong via NANOG > > wrote:
>> Use SLAAC, allocate prefixes from both providers. If you are using multiple 
>> routers, set the priority of the preferred router to high in the RAs. If 
>> you’re using one router, set the preferred prefix as desired in the RAs. 
>> 
>> Owen
>> 
>> I agree this works, but I assume that we would not consider this a consumer 
>> level solution (requires an administrator to make it work).  It also assumes 
>> the local network policy allows for auto-addressing vs. requirement for 
>> DHCP.  
> 
> It shouldn’t require an administrator if there’s just one router. If there 
> are two routers, I’d say we’re beyond the average consumer. 
> 
> 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:
> - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a 
> local cable service and/or DSL service, and/or xPON service

OK, so one router or two?

> - Both providers have IPv6 (competing in the market so don't cooperate on how 
> to address, manage customer homes) 

This shouldn’t be necessary with appropriate CPE, especially if Mr/Ms/Ze Smith 
has a single router for both.

> - Mr/Ms/Ze Smith has no idea what IPv4 is, what IPv6 is or anything anything 
> else technical (typical consumer); They only knows how to walk into a store 
> and buy a random thing off the shelf and ask for "WiFi".

Again, assuming a single router managing both providers with a sane 
implementation and rational defaults, this shouldn’t be a problem.

Of course, today, that isn’t really available in v4 for the most part, either.

> - 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) 

Let’s further pretend that the software in the box is sane about its v6 
implementation and has a “primary” and “backup” port allowing it to make 
rational default choices
about priority/preference fields in the RAs that it generates and that it 
defaults to SLAAC only on the LAN ports.

> - Lets also assume the cable boxes have a consumer actionable way to force 
> R1483 mode, and assume the DSL device can do the same (I know many providers 
> that don't allow this type of configuration)

R1483 is unfamiliar to me unless you mean the RFC covering Multiprotocol 
Encapsulation over ATM Adaptation Layer 5.

Assuming this is what you mean, let me get this straight, we’ve got a consumer 
who doesn’t know what IPv4 or IPv6 are, and she just wants WiFi, but she’s 
supposed to understand what RFC-1483 is and/or the implications of ATM 
Adaptation layer 5 for multi protocol encapsulation? I could be wrong, but I 
think that’s asking a lot.

The CPE should have rational defaults for supporting the two connections, 
period. She shouldn’t need “consumer actionable anything” an it should be 
possible to just plug it in and have it work.

> - So this dual WAN (retail) device now has one Public IPv4 address per WAN 
> interface (assuming one or both of the services was not disallowing bridging 
> mode, in which case its a Private address on one or both of the WAN 
> interfaces)

Sure, but we really don’t care about the IPv4 thing here, that’s going to 
involve tragic NAT hackery and whatever. Hopefully it’s a somewhat temporary 
problem.

> - this dual wan device also gets a PD from both upstream providers which 
> delegates to the CPE

That’s certainly what I would expect.

> I will ignore the dual router case as that normally looks very ugly in 
> networks as customers typically don't hook that up correctly (normally hook 
> one box in behind the first, not in parallel).   Do we think this use case 
> just works today?  Can we say we are confident we know how this all pans out 
> in real production?  e.g. CPE only uses one PD? uses both?  does all the 
> right things to support SLAAC downstream? 

I think that if the CPE has rational defaults (which I admit is not a given 
today) and truly supports IPv6 on the dual WAN ports with proper support for PD 
and corresponding SLAAC on the LAN ports, then yes, this should work.

CPE should use both. It should create RAs with a prefix from the primary port 
PD as preferred,valid,on-link and the secondary port PD as valid,on-link. CPE 
should have no problem doing SLAAC downstream.

I do not know if there are currently any routers that get this right, nor do I 
know if there are not. It’s almost certain there are still CPE routers that get 
this wrong.

> I hate to say it, but for the IPv4 case, 

Re: IPv6 woes - RFC

[Victor Kuarsingh]

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 (consumer level stuff).  Here is my
>> example:
>>
>
> I am afraid you are tailor making your case. We could just as well have an
> even more clueless customer that simply buys a 4G/5G router and attaches it
> to the inside of his LAN in addition to the wifi router he got from his
> DSL/cable/xPON service. Guess what will happen? It wont work as far as IPv4
> goes but it _will_ work with IPv6.
>
> As for the tailor made case where the customer buys a device actually made
> for this, said device would also implement IPv6 for dual WAN. Plenty of
> options for how the device could do that, including the possibility of
> doing 1:1 stateless IPv6 NAT or simply presenting both prefixes to the LAN
> and source route to the correct ISP.
>

You are correct - various cases will have different results (in fact my
main concern is that with consumer gear - there is quite a bit of
variability in what we can expect).

As for my use case, you are right, it was very specific, but that was on
purpose to have a fruitful discussion (versus hand waving things).  I also
wanted to discuss the dual prefix item as well (which was being discussed).
However it is a very real example and shows up in networks (at least in
NA).  I am sure we can draw a very long table of use cases with different
results.

Don't get me wrong, I want IPv6 to work better, I spent a lot of time
implementing IPv6 in multiple networks. That said, I also don't want to
ignore real common uses cases which impact customers and need to be
resolved.

I would like to dig into your use case a bit just so I understand.  I guess
in this case - you assumed the customer would hook up the LTE/5G router
using LAN side ports (no WAN side port).  That makes sense.  I bring this
up because what I had found when looking at direct network data is that
most consumers serialize connecting second routers to each other (but
that's a single provider use case - so I digress).

In this case, when we say "it won't work".  Do we mean nothing works? or
that the effective result of having a redundant connection to two providers
wont work. I agree that only one side, for IPv4 could work as the host
would only get an address from one or the other router.  This is a great
use case for IPv6 in terms of the benefits for dual router situations.

All that said, I do personally (because of impact on call centers and
costs) differentiate outcomes where something "does not have the full
intended redundancy" (but still works and gets people to the Internet)
versus "can supply brokenness driving calls and IT support" (the latter is
more serious in my opinion).

regards,

Victor K


>
> Regards,
>
> Baldur
>
>

Re: IPv6 woes - RFC

[Michael Thomas]

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, Victor Kuarsingh
mailto:vic...@jvknet.com>> 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 the priority of the
preferred router to high in the RAs. If you’re using one
router, set the preferred prefix as desired in the RAs.

Owen


I agree this works, but I assume that we would not consider
this a consumer level solution (requires an administrator to
make it work).  It also assumes the local network policy
allows for auto-addressing vs. requirement for DHCP.


It shouldn’t require an administrator if there’s just one
router. If there are two routers, I’d say we’re beyond the
average consumer.


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:
- Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home
and buy a local cable service and/or DSL service, and/or xPON service


Isn't the easier (and cheaper) thing to do here is just use a VPN
to get behind the corpro firewall? Or as is probably happening
more and more there is no corpro network at all since everything
is outsourced on the net for smaller companies like your law firm.


For shops with IT departments, sure that can make sense. For many 
mom/pop setups, maybe less likely.  The challenge for us (in this 
industry) is that we need to address not just the top use cases, but 
the long tail as well (especially in this new climate of more WFH).


The last startup I worked for a customer wanted audit info on our 
corporate network. We didn't have one. We just used various cloud based 
services to get our jobs done and rented cloud based vm's for the 
customer facing services. I would imagine that a mom/pop setup would do 
the same thing these days. Having a corpro network in the small probably 
doesn't make much sense anymore let alone the fancy multihoming 
scenarios to access it. There are security implications with all of 
this, of course, but that's probably the path of least resistance.


Mike

Re: IPv6 woes - RFC

[Victor Kuarsingh]

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 
>> wrote:
>>
>>> Use SLAAC, allocate prefixes from both providers. If you are using
>>> multiple routers, set the priority of the preferred router to high in the
>>> RAs. If you’re using one router, set the preferred prefix as desired in the
>>> RAs.
>>>
>>> Owen
>>>
>>
>> I agree this works, but I assume that we would not consider this a
>> consumer level solution (requires an administrator to make it work).  It
>> also assumes the local network policy allows for auto-addressing vs.
>> requirement for DHCP.
>>
>>
>> It shouldn’t require an administrator if there’s just one router. If
>> there are two routers, I’d say we’re beyond the average consumer.
>>
>
> 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:
> - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a
> local cable service and/or DSL service, and/or xPON service
>
> Isn't the easier (and cheaper) thing to do here is just use a VPN to get
> behind the corpro firewall? Or as is probably happening more and more there
> is no corpro network at all since everything is outsourced on the net for
> smaller companies like your law firm.
>

For shops with IT departments, sure that can make sense.  For many mom/pop
setups, maybe less likely.  The challenge for us (in this industry) is that
we need to address not just the top use cases, but the long tail as well
(especially in this new climate of more WFH).

regards,

Victor K



>
> The use cases that stuck in my mind for the justification for the need for
> routing was for things like Zigbee and other low power networks where you
> want them isolated from the chatter of the local lan. Not saying that I
> agree with the justification, but that was it iirc.
>
> Mike
>

Re: IPv6 woes - RFC

[Michael Thomas]

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@nanog.org>> wrote:

Use SLAAC, allocate prefixes from both providers. If you are
using multiple routers, set the priority of the preferred
router to high in the RAs. If you’re using one router, set
the preferred prefix as desired in the RAs.

Owen


I agree this works, but I assume that we would not consider this
a consumer level solution (requires an administrator to make it
work).  It also assumes the local network policy allows for
auto-addressing vs. requirement for DHCP.


It shouldn’t require an administrator if there’s just one router.
If there are two routers, I’d say we’re beyond the average consumer.


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:
- Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and 
buy a local cable service and/or DSL service, and/or xPON service


Isn't the easier (and cheaper) thing to do here is just use a VPN to get 
behind the corpro firewall? Or as is probably happening more and more 
there is no corpro network at all since everything is outsourced on the 
net for smaller companies like your law firm.


The use cases that stuck in my mind for the justification for the need 
for routing was for things like Zigbee and other low power networks 
where you want them isolated from the chatter of the local lan. Not 
saying that I agree with the justification, but that was it iirc.


Mike

Re: IPv6 woes - RFC

[Victor Kuarsingh]

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 
> wrote:
>
>> Use SLAAC, allocate prefixes from both providers. If you are using
>> multiple routers, set the priority of the preferred router to high in the
>> RAs. If you’re using one router, set the preferred prefix as desired in the
>> RAs.
>>
>> Owen
>>
>
> I agree this works, but I assume that we would not consider this a
> consumer level solution (requires an administrator to make it work).  It
> also assumes the local network policy allows for auto-addressing vs.
> requirement for DHCP.
>
>
> It shouldn’t require an administrator if there’s just one router. If there
> are two routers, I’d say we’re beyond the average consumer.
>

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:
- Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a
local cable service and/or DSL service, and/or xPON service
- Both providers have IPv6 (competing in the market so don't cooperate on
how to address, manage customer homes)
- Mr/Ms/Ze Smith has no idea what IPv4 is, what IPv6 is or anything
anything else technical (typical consumer); They only knows how to walk
into a store and buy a random thing off the shelf and ask for "WiFi".
- 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)
- Lets also assume the cable boxes have a consumer actionable way to force
R1483 mode, and assume the DSL device can do the same (I know many
providers that don't allow this type of configuration)
- So this dual WAN (retail) device now has one Public IPv4 address per WAN
interface (assuming one or both of the services was not disallowing
bridging mode, in which case its a Private address on one or both of the
WAN interfaces)
- this dual wan device also gets a PD from both upstream providers which
delegates to the CPE

I will ignore the dual router case as that normally looks very ugly in
networks as customers typically don't hook that up correctly (normally hook
one box in behind the first, not in parallel).   Do we think this use case
just works today?  Can we say we are confident we know how this all pans
out in real production?  e.g. CPE only uses one PD? uses both?  does all
the right things to support SLAAC downstream?

I hate to say it, but for the IPv4 case, as ugly as NAT is, I know what
happens and normally the consumer has no clue what's going on and the
router just deals with it. For the IPv6 side, I am not yet confident this
is all just working yet.  I would like to be wrong.  I can say - in my
consumer mode in the US - this example above is not working by default. (I
won't out the providers of course).  I want the answer to be different, but
there is still more work to do (especially since dual provider has become
much more common due to work from home).

regards,

Victor K







>
> I have had IPv6 in my home for a long time now using multiple providers,
> but it definitely works with high touch admin.  I don't see this as a
> barrier to deploy IPv6 though (don't read that into my response).  But IPv6
> still has a few corner cases that require some TLC.
>
>
> It’s not high touch in my environment, but my environment goes way beyond
> consumer and involves ARIN assigned GUA and BGP.
>
> Not every home is the same.
>
> Owen
>
>
> regards,
>
> Victor K
>
>
>
>
>
>
>>
>>
>> On Sep 29, 2021, at 07:35, Christopher Morrow 
>> wrote:
>>
>> 
>>
>>
>> On Wed, Sep 29, 2021 at 4:39 AM  wrote:
>>
>>> Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
>>>
>>> Im currently 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 --
>>>
>>> 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:
>>> >
>>> > 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 d

Re: IPv6 woes - RFC

[Michael Thomas]

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 the priority of the preferred router
to high in the RAs. If you’re using one router, set the preferred
prefix as desired in the RAs.

Owen


I agree this works, but I assume that we would not consider this a 
consumer level solution (requires an administrator to make it work).  
It also assumes the local network policy allows for auto-addressing 
vs. requirement for DHCP.


It shouldn’t require an administrator if there’s just one router. If 
there are two routers, I’d say we’re beyond the average consumer.



I think the multiple router problem is one of the things that homenet 
was supposed to be solving for such that it is plug and play. But I 
share some of your skepticism.


I wonder if anybody has run an experiment wider than one or two people 
where the home router implements a 6-4 NAT and the default numbering is 
v6 instead of v4. That is, run everything that can run on v6 and NAT it 
to v4 on the wan side (assuming there isn't v6 there). There are lots of 
v6 stacks out there for all of the common OS's and supposedly they 
prefer v6 in a happy eyeballs race. I mean, if we have to NAT why not v6 
NAT the devices that support it and v4 NAT the ones that can't.


I'm not sure if Cablelabs is active with v6 -- last I heard they were 
pushing v6, but that's been ages -- but that would really put their 
money where their mouth is if it really worked well at scale. It would 
also give some incentive to have v6 in the last mile so you don't even 
need the 6-4 NAT. Didn't somebody like Comcast go to a complete v6 
network internally to simplify their network? That sounds like it would 
push the simplification even farther.


Mike

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 29, 2021, at 09:25, Victor Kuarsingh  wrote:
> 
> 
> 
> 
>> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG  
>> wrote:
>> Use SLAAC, allocate prefixes from both providers. If you are using multiple 
>> routers, set the priority of the preferred router to high in the RAs. If 
>> you’re using one router, set the preferred prefix as desired in the RAs. 
>> 
>> Owen
> 
> I agree this works, but I assume that we would not consider this a consumer 
> level solution (requires an administrator to make it work).  It also assumes 
> the local network policy allows for auto-addressing vs. requirement for DHCP. 
>  

It shouldn’t require an administrator if there’s just one router. If there are 
two routers, I’d say we’re beyond the average consumer. 

> I have had IPv6 in my home for a long time now using multiple providers, but 
> it definitely works with high touch admin.  I don't see this as a barrier to 
> deploy IPv6 though (don't read that into my response).  But IPv6 still has a 
> few corner cases that require some TLC.

It’s not high touch in my environment, but my environment goes way beyond 
consumer and involves ARIN assigned GUA and BGP. 

Not every home is the same. 

Owen

> 
> regards,
> 
> Victor K
> 
> 
> 
> 
>  
>> 
>> 
>>>> On Sep 29, 2021, at 07:35, Christopher Morrow  
>>>> wrote:
>>>> 
>>> 
>>> 
>>> 
>>>> On Wed, Sep 29, 2021 at 4:39 AM  wrote:
>>>> Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
>>>> 
>>>> Im currently 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 --
>>>> 
>>>> 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:
>>>> > 
>>>> > 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.
>>>> 
>>>> > And if they change ISP they will get new range?
>>>> 
>>>> Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
>>>> has only been specified for 18 years now.  The IPv6 address ranges ISP
>>>> get for RIRs are based on handing out multiple /64 to every customer.
>>>> 
>>>> > Doesnt sounds nice to me.. But I guess I its just me
>>>> 
>>>> It sounds like you need to do some reading about IPv6, then actually
>>>> use it.  100s of millions of home customers are get routable IPv6 prefixes
>>>> today around the world.  It's not scary.  Things don˙˙t blow up.
>>>> 
>>>> > Yeah I am aware of putting additional aliases on loopback.
>>>> > 
>>>> > No futher comment about ND and DHCP.
>>>> > 
>>>> > Well, at a time when TCP/IP was invented, 32bit address space looked
>>>> > pretty much big... I dont blame them than they didnt predicted future..
>>>> > Unfortunately, cant say the same about IPv6 R taskforce ;)
>>>> > 
>>>> > Hah, multicast... Ill skip it.
>>>> > 
>>>> > Followed change to support CIDR, Internet was still small and considered
>>>> > R field...
>>>> > 
>>>> > Okey, I think its no need to futher pollute NANOG list with this.
>>>> > I said at the begining that this is just my subjective opinion.
>>>> > This will not help IPv6 case at all.
>>>> > 
>>>> > At least from my (2) standpoint it would be really cool that IPv6
>>>> > would be finally addopted.
>>>> > 
>>>> > I just wanted to share my toughts about why im not big fan of IPv6.
>>>> > I also wanted to hear other opinions what they dislike about it, no
>>>> > list of how cool IPv6 is and how everyone should use it right away.
>>>> > 
>>>> > 
>>>> > -- Original message --
>>>> > 
>>>> >

Re: IPv6 woes - RFC

[Victor Kuarsingh]

On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG 
wrote:

> Use SLAAC, allocate prefixes from both providers. If you are using
> multiple routers, set the priority of the preferred router to high in the
> RAs. If you’re using one router, set the preferred prefix as desired in the
> RAs.
>
> Owen
>

I agree this works, but I assume that we would not consider this a consumer
level solution (requires an administrator to make it work).  It also
assumes the local network policy allows for auto-addressing vs. requirement
for DHCP.

I have had IPv6 in my home for a long time now using multiple providers,
but it definitely works with high touch admin.  I don't see this as a
barrier to deploy IPv6 though (don't read that into my response).  But IPv6
still has a few corner cases that require some TLC.

regards,

Victor K






>
>
> On Sep 29, 2021, at 07:35, Christopher Morrow 
> wrote:
>
> 
>
>
> On Wed, Sep 29, 2021 at 4:39 AM  wrote:
>
>> Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
>>
>> Im currently 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 --
>>
>> 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:
>> >
>> > 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.
>>
>> > And if they change ISP they will get new range?
>>
>> Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
>> has only been specified for 18 years now.  The IPv6 address ranges ISP
>> get for RIRs are based on handing out multiple /64 to every customer.
>>
>> > Doesnt sounds nice to me.. But I guess I its just me
>>
>> It sounds like you need to do some reading about IPv6, then actually
>> use it.  100s of millions of home customers are get routable IPv6 prefixes
>> today around the world.  It's not scary.  Things don˙˙t blow up.
>>
>> > Yeah I am aware of putting additional aliases on loopback.
>> >
>> > No futher comment about ND and DHCP.
>> >
>> > Well, at a time when TCP/IP was invented, 32bit address space looked
>> > pretty much big... I dont blame them than they didnt predicted future..
>> > Unfortunately, cant say the same about IPv6 R taskforce ;)
>> >
>> > Hah, multicast... Ill skip it.
>> >
>> > Followed change to support CIDR, Internet was still small and considered
>> > R field...
>> >
>> > Okey, I think its no need to futher pollute NANOG list with this.
>> > I said at the begining that this is just my subjective opinion.
>> > This will not help IPv6 case at all.
>> >
>> > At least from my (2) standpoint it would be really cool that IPv6
>> > would be finally addopted.
>> >
>> > I just wanted to share my toughts about why im not big fan of IPv6.
>> > I also wanted to hear other opinions what they dislike about it, no
>> > 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
>> >
>> >
>> >
>> >> 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?
>> >>
>> >> Yeah, IPv6 is new, but its more like revolution instead of evolution.
>> >>
>> >> Well, Industry seems to addapt things quickly when they are good
>> enough.
>> >> Better things replace worse. Of course its not always the case,
>> sometimes
>> >> things are being forced here.. And thats how I feel about IPv6..
>> >
>> > Sometimes worse things replace better. NAT, for example was definitely
>> not
>> > an improvement to IPv4. It was a necessary evil intended to be a
>> temporary
>> > fix.
>> >
>> >>
>> >>

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

Use SLAAC, allocate prefixes from both providers. If you are using multiple 
routers, set the priority of the preferred router to high in the RAs. If you’re 
using one router, set the preferred prefix as desired in the RAs. 

Owen


> On Sep 29, 2021, at 07:35, Christopher Morrow  wrote:
> 
> 
> 
> 
>> On Wed, Sep 29, 2021 at 4:39 AM  wrote:
>> Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
>> 
>> Im currently 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 --
>> 
>> 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:
>> > 
>> > 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.
>> 
>> > And if they change ISP they will get new range?
>> 
>> Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
>> has only been specified for 18 years now.  The IPv6 address ranges ISP
>> get for RIRs are based on handing out multiple /64 to every customer.
>> 
>> > Doesnt sounds nice to me.. But I guess I its just me
>> 
>> It sounds like you need to do some reading about IPv6, then actually
>> use it.  100s of millions of home customers are get routable IPv6 prefixes
>> today around the world.  It's not scary.  Things don˙˙t blow up.
>> 
>> > Yeah I am aware of putting additional aliases on loopback.
>> > 
>> > No futher comment about ND and DHCP.
>> > 
>> > Well, at a time when TCP/IP was invented, 32bit address space looked
>> > pretty much big... I dont blame them than they didnt predicted future..
>> > Unfortunately, cant say the same about IPv6 R taskforce ;)
>> > 
>> > Hah, multicast... Ill skip it.
>> > 
>> > Followed change to support CIDR, Internet was still small and considered
>> > R field...
>> > 
>> > Okey, I think its no need to futher pollute NANOG list with this.
>> > I said at the begining that this is just my subjective opinion.
>> > This will not help IPv6 case at all.
>> > 
>> > At least from my (2) standpoint it would be really cool that IPv6
>> > would be finally addopted.
>> > 
>> > I just wanted to share my toughts about why im not big fan of IPv6.
>> > I also wanted to hear other opinions what they dislike about it, no
>> > 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
>> > 
>> > 
>> > 
>> >> 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?
>> >> 
>> >> Yeah, IPv6 is new, but its more like revolution instead of evolution.
>> >> 
>> >> Well, Industry seems to addapt things quickly when they are good enough.
>> >> Better things replace worse. Of course its not always the case, sometimes
>> >> things are being forced here.. And thats how I feel about IPv6..
>> > 
>> > Sometimes worse things replace better. NAT, for example was definitely not
>> > an improvement to IPv4. It was a necessary evil intended to be a temporary
>> > fix.
>> > 
>> >> 
>> >> IPv4 Lookback is 127.0.0.1/8
>> >> You can use bind IPs within range by applications. Handy
>> >> In IPv6 its not the case.
>> > 
>> > You are free to assign any additional IPv6 addresses you like to the 
>> > loopback
>> > interface and then bind them to applications. Personally, I haven˙˙t found 
>> > a
>> > particularly good use for this, but it is possible.
>> > 
>> > It does mean that instead of wasting 1/256th of the entire address space
>> > in every context on loopbacks, you have to assign what you need there,
>> >

Re: IPv6 woes - RFC

[Christopher Morrow]

On Wed, Sep 29, 2021 at 4:39 AM  wrote:

> Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
>
> Im currently 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 --
>
> 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:
> >
> > 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.
>
> > And if they change ISP they will get new range?
>
> Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
> has only been specified for 18 years now.  The IPv6 address ranges ISP
> get for RIRs are based on handing out multiple /64 to every customer.
>
> > Doesnt sounds nice to me.. But I guess I its just me
>
> It sounds like you need to do some reading about IPv6, then actually
> use it.  100s of millions of home customers are get routable IPv6 prefixes
> today around the world.  It's not scary.  Things don˙˙t blow up.
>
> > Yeah I am aware of putting additional aliases on loopback.
> >
> > No futher comment about ND and DHCP.
> >
> > Well, at a time when TCP/IP was invented, 32bit address space looked
> > pretty much big... I dont blame them than they didnt predicted future..
> > Unfortunately, cant say the same about IPv6 R taskforce ;)
> >
> > Hah, multicast... Ill skip it.
> >
> > Followed change to support CIDR, Internet was still small and considered
> > R field...
> >
> > Okey, I think its no need to futher pollute NANOG list with this.
> > I said at the begining that this is just my subjective opinion.
> > This will not help IPv6 case at all.
> >
> > At least from my (2) standpoint it would be really cool that IPv6
> > would be finally addopted.
> >
> > I just wanted to share my toughts about why im not big fan of IPv6.
> > I also wanted to hear other opinions what they dislike about it, no
> > 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
> >
> >
> >
> >> 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?
> >>
> >> Yeah, IPv6 is new, but its more like revolution instead of evolution.
> >>
> >> Well, Industry seems to addapt things quickly when they are good enough.
> >> Better things replace worse. Of course its not always the case,
> sometimes
> >> things are being forced here.. And thats how I feel about IPv6..
> >
> > Sometimes worse things replace better. NAT, for example was definitely
> not
> > an improvement to IPv4. It was a necessary evil intended to be a
> temporary
> > fix.
> >
> >>
> >> IPv4 Lookback is 127.0.0.1/8
> >> You can use bind IPs within range by applications. Handy
> >> In IPv6 its not the case.
> >
> > You are free to assign any additional IPv6 addresses you like to the
> loopback
> > interface and then bind them to applications. Personally, I haven˙˙t
> found a
> > particularly good use for this, but it is possible.
> >
> > It does mean that instead of wasting 1/256th of the entire address space
> > in every context on loopbacks, you have to assign what you need there,
> > but you can easily assign a /64 prefix to a loopback interface and have
> > applications bind within range.
> >
> >> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
> >> Tables overflows, attacks and DDoS.. Why to repeat history again?
> >
> > Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs.
> > ARP. Table overflows are (not really an issue in my experience) the
> > result of a larger address space than the memory available for the L2
> > forwarding table on switches or the ND table on hosts. This isn˙˙t due
> > to a difference in ND vs. ARP. It is due to the fact that there are no
> > 64-bit networks in IPv4, but they are commonplace in IPv6.

Re: IPv6 woes - RFC

[Christopher Morrow]

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 made in the paper i cited
>

"This is a preview of subscription content, log in

to
check access."
  

I can see a wierdo looking image with 'port scan data', which roughly seems
to say:
  "Hey, turn on the firewall"
on all of their tested devices... and what look like 'cablelabs affiliates'
mostly did
the right thing with that fw policy.


> > I also thought 'homenet' (https://datatracker.ietf.org/wg/homenet) was
> > supposed to have provided the guidance you seek here?
>
> got a cite for the guidance?
>
>
sure, that's in the referenced architecture document from your link
(one of the other few things I can see is the references section):
  3. Chown, T., Arkko, J., Brandt, A., Troan, O., Weil, J.: IPv6 home
networking
 architecture principles. RFC 7368, Internet Engineering Task Force
(October 2014)

The points about NAT in v4 being 'helpful' are sort of right, but the
attacks just
move up the stack[0] :( so I don't think it's particularly germaine to
worry/not about nat
for 'security' purposes.

-chris

0: https://us.norton.com/internetsecurity-malware-malvertising.html
(NOTE: I'm not a fan of norton nor any AV really, but.. the article
makes the
'up the stack' point)

Re: IPv6 woes - RFC

[borg]

Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?

Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy
routing and NATing however I want..


-- 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:
> 
> 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.

> And if they change ISP they will get new range?

Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
has only been specified for 18 years now.  The IPv6 address ranges ISP
get for RIRs are based on handing out multiple /64 to every customer.

> Doesnt sounds nice to me.. But I guess I its just me

It sounds like you need to do some reading about IPv6, then actually
use it.  100s of millions of home customers are get routable IPv6 prefixes
today around the world.  It's not scary.  Things don˙˙t blow up.

> Yeah I am aware of putting additional aliases on loopback.
> 
> No futher comment about ND and DHCP.
> 
> Well, at a time when TCP/IP was invented, 32bit address space looked
> pretty much big... I dont blame them than they didnt predicted future..
> Unfortunately, cant say the same about IPv6 R taskforce ;)
> 
> Hah, multicast... Ill skip it.
> 
> Followed change to support CIDR, Internet was still small and considered
> R field...
> 
> Okey, I think its no need to futher pollute NANOG list with this.
> I said at the begining that this is just my subjective opinion.
> This will not help IPv6 case at all.
> 
> At least from my (2) standpoint it would be really cool that IPv6
> would be finally addopted.
> 
> I just wanted to share my toughts about why im not big fan of IPv6.
> I also wanted to hear other opinions what they dislike about it, no
> 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
> 
> 
> 
>> 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?
>> 
>> Yeah, IPv6 is new, but its more like revolution instead of evolution.
>> 
>> Well, Industry seems to addapt things quickly when they are good enough.
>> Better things replace worse. Of course its not always the case, sometimes
>> things are being forced here.. And thats how I feel about IPv6..
> 
> Sometimes worse things replace better. NAT, for example was definitely not
> an improvement to IPv4. It was a necessary evil intended to be a temporary
> fix.
> 
>> 
>> IPv4 Lookback is 127.0.0.1/8
>> You can use bind IPs within range by applications. Handy
>> In IPv6 its not the case.
> 
> You are free to assign any additional IPv6 addresses you like to the loopback
> interface and then bind them to applications. Personally, I haven˙˙t found a
> particularly good use for this, but it is possible.
> 
> It does mean that instead of wasting 1/256th of the entire address space
> in every context on loopbacks, you have to assign what you need there,
> but you can easily assign a /64 prefix to a loopback interface and have
> applications bind within range.
> 
>> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
>> Tables overflows, attacks and DDoS.. Why to repeat history again?
> 
> Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs.
> ARP. Table overflows are (not really an issue in my experience) the
> result of a larger address space than the memory available for the L2
> forwarding table on switches or the ND table on hosts. This isn˙˙t due
> to a difference in ND vs. ARP. It is due to the fact that there are no
> 64-bit networks in IPv4, but they are commonplace in IPv6.
> 
> Mostly this has been solved in software by managing table discards more
> effectively.
> 
>> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some 
>> issues. If this is not the case, im sorry. Its been a while when I last time
>> played with IPv6...
> 
> I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any 
> significant
> problems with it other than some minor inconveniences introduced by the 
> ability
> to have different DUID types and vendors doing semi-obnoxious things along 
> that
> line.
> 
>> IPv6 interop: yeah, I agre

Re: IPv6 woes - RFC

[Saku Ytti]

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 lack of standardisation in home automation limits the
total size of the market. So we're getting a nice network protocol;
thread and nice application protocol; matter to enable vendors to sell
more products to us. As a side effect, we also increase security quite
a bit, due to the thread network not having public addresses and will
communicate only to the gateway.
Many of us already have thread gateway at home, via homepod mini or
google nest and increasingly so will get one.

Amazing what commercially motivated standards can do in a short time,
when not ran through IETF.

-- 
  ++ytti

Re: IPv6 woes - RFC

[Victor Kuarsingh]

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

[Randy Bush]

> https://datatracker.ietf.org/doc/html/rfc6092

good stuff.  thanks.

Re: IPv6 woes - RFC

[Mark Andrews]

> 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 Access Control Policies in
>Residential Networks; 
>Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife
> 
>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

Really?

RFC6092 January 2011

Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service

https://datatracker.ietf.org/doc/html/rfc6092

CableLabs has similar requirements.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: IPv6 woes - RFC

[Randy Bush]

>> 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://datatracker.ietf.org/wg/homenet) was
> supposed to have provided the guidance you seek here?

got a cite for the guidance?

randy

Re: IPv6 woes - RFC

[Michael Thomas]

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.  and it can have consequences, see

    NATting Else Matters: Evaluating IPv6 Access Control Policies in
    Residential Networks;
    Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife

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


guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) 
is likely to impact all of our security 'requirements'. :(
I also thought 'homenet' (https://datatracker.ietf.org/wg/homenet 
) was supposed to have 
provided the

guidance you seek here?



What I wonder is which string the IETF has to push on to get CPE vendors 
to... anything.


Anecdotally, I've seen firewall controls on all of the CPE I've had and 
no IPv6 (at least commercially).


Mike

Re: IPv6 woes - RFC

[Christopher Morrow]

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 Access Control Policies in
> Residential Networks;
> Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife
>
>
> 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
>
>
guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) is
likely to impact all of our security 'requirements'. :(
I also thought 'homenet' (https://datatracker.ietf.org/wg/homenet) was
supposed to have provided the
guidance you seek here?

Re: IPv6 woes - RFC

[Randy Bush]

> 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; 
Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife

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

randy

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 outside.
> 
> Do you mean, because of hole punching, "not routable" does not mean
> that it is "not reachable from outside"?
> 
>>> And if they change ISP they will get new range?
>> Yes!
> 
> The problem is that IPv6 was promised to perform *AUTOMATIC*
> *RENUMBERING*, with which, even if address ranges change, all
> the configuration information, including those for DNS glues,
> can be automatically updated.

Sure it can… That’s just software.

> With careful design by real experts, it is possible to design
> such a protocol even with IPv4 but IPv6 "committee" naturally
> abandoned to do so with IPv6.

What’s missing? We already have DDNS and DHCP is already capable of 
doing what’s needed to update the DNS server there.

If you don’t like DDNS, then there are relatively simple ways to script DNS 
updates for prefix changes as well.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 28, 2021, at 02:19 , b...@uu3.net 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?

NAT is absolutely that evil after all. The presence of NAT has basically
prevented a number of products that I think would have been really
cool from being developed because they just aren’t practical without
end to end addressing.

A routable GUA for every device…Yes, yes, please yes!!!
Not necessarily reachable from outside (stateful inspection
can still take care of that, you don’t have to mutilate the packet
headers in the process).

> And if they change ISP they will get new range?

Yes. It’s all dynamic addressed anyway, so who cares?

> Doesnt sounds nice to me.. But I guess I its just me

What’s the difference between keeping the same NAT’d v4 with
a new public translated address and a new public address other
than easier event correlation, readable audit logs, and consistency?

> Yeah I am aware of putting additional aliases on loopback.
> 
> No futher comment about ND and DHCP.
> 
> Well, at a time when TCP/IP was invented, 32bit address space looked
> pretty much big... I dont blame them than they didnt predicted future..
> Unfortunately, cant say the same about IPv6 R taskforce ;)

Sure, but it wasn’t expected to be a global consumer network. It was intended
to be an R network shared primarily among the military and universities and
a few other research institutions.

> Hah, multicast... Ill skip it.
> 
> Followed change to support CIDR, Internet was still small and considered
> R field...

CIDR was the precursor to NAT largely as a result of the progress of the same
forces that got us where we are today… The internet becoming popular among
audiences it was never originally intended to reach.

> I just wanted to share my toughts about why im not big fan of IPv6.
> I also wanted to hear other opinions what they dislike about it, no
> list of how cool IPv6 is and how everyone should use it right away.

Well, if you just want an IPv6 complaint fest, then you should probably go find
one of the various lists dedicated to doing that. On NANOG, you’re more likely
to get a balanced practical set of opinions from operators discussing both the
good and the bad with a healthy dose of 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
> 
> 
> 
>> 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?
>> 
>> Yeah, IPv6 is new, but its more like revolution instead of evolution.
>> 
>> Well, Industry seems to addapt things quickly when they are good enough.
>> Better things replace worse. Of course its not always the case, sometimes
>> things are being forced here.. And thats how I feel about IPv6..
> 
> Sometimes worse things replace better. NAT, for example was definitely not
> an improvement to IPv4. It was a necessary evil intended to be a temporary
> fix.
> 
>> 
>> IPv4 Lookback is 127.0.0.1/8
>> You can use bind IPs within range by applications. Handy
>> In IPv6 its not the case.
> 
> You are free to assign any additional IPv6 addresses you like to the loopback
> interface and then bind them to applications. Personally, I haven˙˙t found a
> particularly good use for this, but it is possible.
> 
> It does mean that instead of wasting 1/256th of the entire address space
> in every context on loopbacks, you have to assign what you need there,
> but you can easily assign a /64 prefix to a loopback interface and have
> applications bind within range.
> 
>> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
>> Tables overflows, attacks and DDoS.. Why to repeat history again?
> 
> Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs.
> ARP. Table overflows are (not really an issue in my experience) the
> result of a larger address space than the memory available for the L2
> forwarding table on switches or the ND table on hosts. This isn˙˙t due
> to a difference in ND vs. ARP. It is due to the fact that there are no
> 64-bit networks in IPv4, but they are commonplace in IPv6.
> 
> Mostly this has been solved in software by managing table discards more
> effectively.
> 
>> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some 
>> issues. If this is not the case, im sorry. Its been a while when I last time
>> played with IPv6...
> 
> I am u

Re: IPv6 woes - RFC

[Masataka Ohta]

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 mean
that it is "not reachable from outside"?


And if they change ISP they will get new range?


Yes!


The problem is that IPv6 was promised to perform *AUTOMATIC*
*RENUMBERING*, with which, even if address ranges change, all
the configuration information, including those for DNS glues,
can be automatically updated.

With careful design by real experts, it is possible to design
such a protocol even with IPv4 but IPv6 "committee" naturally
abandoned to do so with IPv6.

Masataka Ohta

Re: IPv6 woes - RFC

[Mark Andrews]

> On 28 Sep 2021, at 19:19, b...@uu3.net 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.

> And if they change ISP they will get new range?

Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
has only been specified for 18 years now.  The IPv6 address ranges ISP
get for RIRs are based on handing out multiple /64 to every customer.

> Doesnt sounds nice to me.. But I guess I its just me

It sounds like you need to do some reading about IPv6, then actually
use it.  100s of millions of home customers are get routable IPv6 prefixes
today around the world.  It's not scary.  Things don’t blow up.

> Yeah I am aware of putting additional aliases on loopback.
> 
> No futher comment about ND and DHCP.
> 
> Well, at a time when TCP/IP was invented, 32bit address space looked
> pretty much big... I dont blame them than they didnt predicted future..
> Unfortunately, cant say the same about IPv6 R taskforce ;)
> 
> Hah, multicast... Ill skip it.
> 
> Followed change to support CIDR, Internet was still small and considered
> R field...
> 
> Okey, I think its no need to futher pollute NANOG list with this.
> I said at the begining that this is just my subjective opinion.
> This will not help IPv6 case at all.
> 
> At least from my (2) standpoint it would be really cool that IPv6
> would be finally addopted.
> 
> I just wanted to share my toughts about why im not big fan of IPv6.
> I also wanted to hear other opinions what they dislike about it, no
> 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
> 
> 
> 
>> 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?
>> 
>> Yeah, IPv6 is new, but its more like revolution instead of evolution.
>> 
>> Well, Industry seems to addapt things quickly when they are good enough.
>> Better things replace worse. Of course its not always the case, sometimes
>> things are being forced here.. And thats how I feel about IPv6..
> 
> Sometimes worse things replace better. NAT, for example was definitely not
> an improvement to IPv4. It was a necessary evil intended to be a temporary
> fix.
> 
>> 
>> IPv4 Lookback is 127.0.0.1/8
>> You can use bind IPs within range by applications. Handy
>> In IPv6 its not the case.
> 
> You are free to assign any additional IPv6 addresses you like to the loopback
> interface and then bind them to applications. Personally, I haven˙˙t found a
> particularly good use for this, but it is possible.
> 
> It does mean that instead of wasting 1/256th of the entire address space
> in every context on loopbacks, you have to assign what you need there,
> but you can easily assign a /64 prefix to a loopback interface and have
> applications bind within range.
> 
>> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
>> Tables overflows, attacks and DDoS.. Why to repeat history again?
> 
> Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs.
> ARP. Table overflows are (not really an issue in my experience) the
> result of a larger address space than the memory available for the L2
> forwarding table on switches or the ND table on hosts. This isn˙˙t due
> to a difference in ND vs. ARP. It is due to the fact that there are no
> 64-bit networks in IPv4, but they are commonplace in IPv6.
> 
> Mostly this has been solved in software by managing table discards more
> effectively.
> 
>> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some 
>> issues. If this is not the case, im sorry. Its been a while when I last time
>> played with IPv6...
> 
> I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any 
> significant
> problems with it other than some minor inconveniences introduced by the 
> ability
> to have different DUID types and vendors doing semi-obnoxious things along 
> that
> line.
> 
>> IPv6 interop: yeah, I agree here.. But people involved with IPv6 should 
>> think about some external IPv4 interop.. Internet was exploding at 1997..
>> Maybe they had hope that everyone upgrade like in CIDR case. And maybe it 
>> could happen if IPv6 wasnt so alien ;)
> 
> It was thought about˙˙ It was considered. It was long pondere

Re: IPv6 woes - RFC

[borg]

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?
And if they change ISP they will get new range?
Doesnt sounds nice to me.. But I guess I its just me

Yeah I am aware of putting additional aliases on loopback.

No futher comment about ND and DHCP.

Well, at a time when TCP/IP was invented, 32bit address space looked
pretty much big... I dont blame them than they didnt predicted future..
Unfortunately, cant say the same about IPv6 R taskforce ;)

Hah, multicast... Ill skip it.

Followed change to support CIDR, Internet was still small and considered
R field...

Okey, I think its no need to futher pollute NANOG list with this.
I said at the begining that this is just my subjective opinion.
This will not help IPv6 case at all.

At least from my (2) standpoint it would be really cool that IPv6
would be finally addopted.

I just wanted to share my toughts about why im not big fan of IPv6.
I also wanted to hear other opinions what they dislike about it, no
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



> 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?
> 
> Yeah, IPv6 is new, but its more like revolution instead of evolution.
> 
> Well, Industry seems to addapt things quickly when they are good enough.
> Better things replace worse. Of course its not always the case, sometimes
> things are being forced here.. And thats how I feel about IPv6..

Sometimes worse things replace better. NAT, for example was definitely not
an improvement to IPv4. It was a necessary evil intended to be a temporary
fix.

> 
> IPv4 Lookback is 127.0.0.1/8
> You can use bind IPs within range by applications. Handy
> In IPv6 its not the case.

You are free to assign any additional IPv6 addresses you like to the loopback
interface and then bind them to applications. Personally, I haven˙˙t found a
particularly good use for this, but it is possible.

It does mean that instead of wasting 1/256th of the entire address space
in every context on loopbacks, you have to assign what you need there,
but you can easily assign a /64 prefix to a loopback interface and have
applications bind within range.

> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
> Tables overflows, attacks and DDoS.. Why to repeat history again?

Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs.
ARP. Table overflows are (not really an issue in my experience) the
result of a larger address space than the memory available for the L2
forwarding table on switches or the ND table on hosts. This isn˙˙t due
to a difference in ND vs. ARP. It is due to the fact that there are no
64-bit networks in IPv4, but they are commonplace in IPv6.

Mostly this has been solved in software by managing table discards more
effectively.

> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some 
> issues. If this is not the case, im sorry. Its been a while when I last time
> played with IPv6...

I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant
problems with it other than some minor inconveniences introduced by the ability
to have different DUID types and vendors doing semi-obnoxious things along that
line.

> IPv6 interop: yeah, I agree here.. But people involved with IPv6 should 
> think about some external IPv4 interop.. Internet was exploding at 1997..
> Maybe they had hope that everyone upgrade like in CIDR case. And maybe it 
> could happen if IPv6 wasnt so alien ;)

It was thought about˙˙ It was considered. It was long pondered. Problem was,
nobody could come up with a way to overcome the fact that you can˙˙t put
128 bits of data in a 32 bit field without loss.

IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes
necessary to implement IPv6 were significantly bigger than CIDR and IPv6
affected applications, not just network. There was no way around these
two facts. The IPv6 network stack did get adopted and implemented nearly
as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support
for quite some time now at the network stack level. It is applications and
content providers that are lagging and they never did anything for CIDR.

> As for IPv4 vs IPv6 complexity, again, why repeat history.

What complexity?

> Biggest IPv4
> mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.

No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been
inconvenient in hardware at the time, but it would have made IPv4 much more
scalable and would have allowed it

Re: IPv6 woes - RFC

[Jim Young via NANOG]

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.010.010
> PING 010.010.010.010 (8.8.8.8): 56 data bytes
> 64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=27.496 ms
> 
> --- 010.010.010.010 ping statistics ---
> 1 packets transmitted, 1 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 27.496/27.496/27.496/0.000 ms
% 

Re: IPv6 woes - RFC

[Masataka Ohta]

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 represent them, which is described
in rfc810 as:

::=  "."  "."  "." 
::= <0 to 255 decimal>

Obviously, syntax was extended, at least beyond decimal, by a
BSD implementation with language C.

Masataka Ohta

Re: IPv6 woes - RFC

[Nick Hilliard]

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
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms
^C
--- 2130706433 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time84ms
rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms

Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9.


this is a good example of "might work but don't depend on it".  The fact 
that it works at all is a historical curiosity which happened because 
the text format for ipv4 addresses was never formally specified, so when 
some of the tcp/ip code was originally written for bsd, it accepted 
unusual formats in some places, including: integers, octal, hex, binary 
and assuming zeros when the address is incompletely specified, among 
other things.


The octal representation was a real problem because rfc790 specified 
decimal dotted quad notation with leading zeros, leading to a whole bag 
of pain for parsers because there is no way of knowing what a leading 
zero means in practice, and for 3-digit numbers where each digit is <= 
7, there is no a-priori way of determining whether it's octal 
representation or decimal.


Nick

Re: IPv6 woes - RFC

[Chris Adams]

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 works) or 008.008.008.008 (which does not),
is broken.

-- 
Chris Adams 

Re: IPv6 woes - RFC

[Andy Smith]

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

[James R Cutler]

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 value.
> 
> 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
> 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms
> ^C
> --- 2130706433 ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 84ms
> rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms
> 
> Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9.
> 
> That's a bit more than just 'some ancient systems' - depending whether
> it works on other Android releases, and what IoT systems do, we may have
> more systems today that support it than don't support it.

It also works on this 'ancient' macOS Monterey system.

Last login: Sat Sep 25 20:50:00 on ttys000
xz4gb8 ~ % ping 2130706433
PING 2130706433 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.047 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.111 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.103 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.109 ms
^C
--- 2130706433 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.047/0.092/0.111/0.026 ms
xz4gb8 ~ % 

Re: IPv6 woes - RFC

[Valdis Klētnieks]

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) 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
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms
^C
--- 2130706433 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 84ms
rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms

Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9.

That's a bit more than just 'some ancient systems' - depending whether
it works on other Android releases, and what IoT systems do, we may have
more systems today that support it than don't support it.

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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
> of any concern unless you’re making the mistake of trying to
> string wise compare them in their text-representation format.
> Both equate to the same uint128_t value.
> 
> If you adhere to RFC 5952 only the former is to be used (2001:db8:0:1::5). 
> Also strict RFC 5952 on any output will make a string compare ok because 
> there is only one way to print any address.

IIRC 5952 only specifies display, it does not control (and even if it purports 
to, depending users to comply is silly) user input.

> 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. 

Truth.

> You can even encounter IPv4 printed as IPv6 which is not too uncommon. Many 
> programs internally are IPv6 only and IPv4 is therefore mapped to IPv6. It 
> appears some people are forgetting this fact when proposing to drop IPv6.

Fair point.

I think that :::1.2.3.4 is fine and I doubt it confuses anyone in IPv4 land 
much.

Owen

Re: IPv6 woes - RFC

[Baldur Norddahl]

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 their text-representation format.
> Both equate to the same uint128_t value.


If you adhere to RFC 5952 only the former is to be used (2001:db8:0:1::5).
Also strict RFC 5952 on any output will make a string compare ok because
there is only one way to print any address.

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.

You can even encounter IPv4 printed as IPv6 which is not too uncommon. Many
programs internally are IPv6 only and IPv4 is therefore mapped to IPv6. It
appears some people are forgetting this fact when proposing to drop IPv6.

Regards,

Baldur

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 necessary using /32 prefix..
> It just range thats reserved for LL.

So you want to reserve the range 0:0:1:0..0:0::0 with all zeros in the last
16 bits as loopback? Why the (effectively discontiguous net mask)?
Why not include 0:0:0:0 in it?

Sorry, not trying to rain on your parade, but trying to understand your 
thinking here.

> Same about RFC1918 aka space.. its a range reserved for local addreses.

My point was why repeat the RFC-1918 mistake. There’s really no need for
it unless you intend to recreate the NAT problems.

Further, you specified:
0:0:0:1/48 as loopback, that’s the range 0:0:0:0..0:0:0: in your 
proposed
addressing structure.

0:0:1-:0/16 as RFC-1918, that’s an odd way of notating 
0:0:0:0..0::: 
in your proposed addressing structure. As such, your meaning is 
unclear.

So it’s unclear how you intend to map ranges and netmxasks in your proposal.

> The whole rationale is:
> - shorter prefix wins (so no overlap?)

Usually longest matching prefix wins, but when you’re talking about the 
distinction
between RFC-1918 and loopback, I think overlap poses a human factors problem
that you haven’t considered.

> - you can use nice short addreses like ::1234 for loopback
>  or ::1: for LL or ::1:0:1234 for RFC1918 like

Not to put too fine a point on it, but ::1 works in IPv6 today. If you want, you
are free to assign anything else you want on the loopback interface, so for
example, you could assign fd:0:0:1::/64 to the loopback interface and use
any address you want from fd:0:0:1::0 through fd:0:0:1:::: as
loopback addresses. (I don’t see a point in using GUA for loopback as long
as the ULA silliness exists. In fact, this might be the one and only legitimate
use case I can see for ULA.)

For RFC1918, you can make up anything you want within fd::/8 in IPv6
as it exists today. Ideally, you choose a randomized /48 from fd::/8 and
subnet that along /64 boundaries, but I don’t see that as significantly more
complex than what I think you are proposing.

> Whole ::1 short format should be used only to cut leading zeros
> not "more zeroes whatnever they appear".

Why? The current format allows you to put the :: wherever you think
it makes the most sense and as long as there’s only one :: in an
address (which is a requirement), there’s no ambiguity about the
number of 0s replaced.

Yes, it makes textual comparison of addresses messy, but there’s
really no need for that. Far better use textual representations only
for user presentation anyway. Internally, they should always be
stored/handled as a 128-bit unsigned integer value.

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 their text-representation format.
Both equate to the same uint128_t value.

> ND is new thing and it requires new things to protect it from attacks?

Not so much.

The defined ND attacks aren’t new for ND. They all exist in ARP as well.
What is new is 64-bit wide network segments. If you put a /6 on a switch
in IPv4 and then do an ARP scan, you’ll get the same table overflow
problems as you are talking about with “ND attacks”. The difference is
that in IPv4, /6 networks are extraordinarily rare (if any exist at all) while
it is commonplace in IPv6 to have /64 network segments.

Nonetheless, this isn’t actually inherent in the difference between ND ad
ARP, it is inherent in the difference between network segments limited
to 1024 possible host addresses or less and network segments that have
more than 18 Quintillion possible host addresses.

In fact, if you’re really super-worried about this (which isn’t really a thing
in most environments, TBH), you can create your IPv6 networks as /120s
or /118s or whatever and simply limit the total number of available host
addresses. You have to give up some IPv6 features that don’t exist in
IPv4 anyway, but ND will still work and you won’t have to worry about
table overflows any more than you did in IPv4.

> While all the hate towards NAT, after years of using it I see it as cool
> thing now. Yeah it breaks E2E, and thats why its place is only at CPE.
> The true tragedy is CGN.

So making the average household a second-class citizen on the network
is “cool thing now”? Not in my opinion. There are lots of applications that
should exist today and don’t because we chose to break the E2E model.
Of the applications that do, there is a great deal of added complexity,
fragility, and a loss of privacy due to the use of rendezvous hosts to
overcome the 

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

te criticism of IPv6, which
ones are legitimate criticism, but not actually IPv6, and which ones
are simply 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 
> 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:
>> 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 greater than the 
> delta
> between IPv4 and IPX?
> 
> If anything, I think the delta between IPv4 and IPv6 is too small. Small 
> enough
> that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction
> between the multiple personalities therein.  I also think that the grouping of
> IPv4 and IPv6 as one protocol is part of the downfall.
> 
> More over if you think of IPv4 and IPv6 dual stack as analogous to the
> multi-protocol networks of the '90s, and treat them as disparate protocols 
> that
> serve similar purposes in (completely) different ways, a lot of the friction
> seems to make sense and as such becomes less friction through understanding 
> and
> having reasonable expectations for the disparate protocols.
> 
>> 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.
> 
> I don't think you truly mean that having a new protocol is fine. Because if 
> you
> did, I think you would treat IPv6 as a completely different protocol from 
> IPv4.
> E.g. AppleTalk vs DECnet.  After all, we effectively do have a new protocol;
> IPv6.
> 
> IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98.  Or
> "different" in place of "similar".
> 
>> It should just fix problem (do we have other problems I am not aware of with
>> IPv4?) of address space and thats it.  Im happy with IPv4, after 30+ years of
>> usage we pretty much fixed all problems we had.
> 
> I disagree.
> 
>> The second failure is adoption. Even if my IPv6 hate is not rational, 
>> adoption
>> of IPv6 is crap. If adoption would be much better, more IPv4 could be used 
>> for
>> legacy networks ;) So stuborn guys like me could be happy too ;)
> 
> I blame the industry, not the IPv6 protocol, for the lackluster adoption of
> IPv6.
> 
>> As for details, that list is just my dream IPv6 protocol ;)
>> 
>> But lets talk about details:
>> - Loopback on IPv6 is ::1/128
>>   I have setups where I need more addresses there that are local only.
>>   Yeah I know, we can put extra aliases on interfaces etc.. but its extra
>>   work and not w/o problems
> 
> How does IPv6 differ from IPv4 in this context?
> 
>> - IPv6 Link Local is forced.
>>   I mean, its always on interface, nevermind you assign static IP.
>>   LL is still there and gets in the way (OSPFv3... hell yeah)
> 
> I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices 
> do
> on a network.  But I don't see a technical problem with this in and of itself.
> --  I can't speak to OSPFv3 issues.
> 
>> - ULA space, well.. its like RFC1918 but there are some issues with it
>>   (or at least was? maybe its fixed) like source IP selection on with
>>   multiple addresses.
> 
> I consider this to be implementation issues and not a problem with the 
> protocol
> itself.
> 
>> - Neighbor Discovery protocol... quite a bit problems it created.
> 
> Please elaborate.
> 
>>   What was wrong w/ good old ARP? I tought we fixed all those problems
>>   already like ARP poisoning via port security.. etc
> 
> The apparent need to ""fix / address / respond to a protocol problem at a 
> lower
> layer seems like a problem to me.
> 
>> - NAT is there in IPv6 so no futher comments
>> - DHCP start to get working on IPv6.. but it still pain sometimes
> 
> What problems do you have with DHCP for IPv6?  I've been using it for the 
> better
> part of a decade without any known problems.  What pain are you experiencing?
> 
>> And biggest problem, interop w/ IPv4 was completly failure.
> 
> I agree that the interoperability between IPv4 and IPv6 is the tall pole in 
> the
> tent.  But I also believe that's to be expected when trying to interoperate
> dispa

Re: IPv6 woes - RFC

[Baldur Norddahl]

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 ::2: icmp_seq=1 ttl=64 time=0.043 ms

While I am not sure what use extra addresses from the 127.0.0.0/8 prefix are
on the loopback, it is quite common for us to add extra global addresses
and then use that with proxy arp. Of course that is only necessary on IPv4
since IPv6 isn't so restrained that we have to save every last address bit
using tricks.


>
> - you can use nice short addreses like ::1234 for loopback
>

root@jump2:~# ip addr add ::1234/128 dev lo
root@jump2:~# ping6 ::1234
PING ::1234(::1234) 56 data bytes
64 bytes from ::1234: icmp_seq=1 ttl=64 time=0.046 ms

:-)


>   or ::1: for LL or ::1:0:1234 for RFC1918 like
>

With IPv6 you can use fe80::1: for link local and fd00::1:0:1234 for
your RFC1918 like setup. And then you can use 1:1 NAT to transform that to
GUA on the router. Even NAT, if you insist on using it, is better with IPv6.

The confusion here appears to be that auto generated link local prefixes
are long with many hex digits. But compared to the new proposal, which
could have no auto generated link local due to having too few bits, there
is nothing that stops you from manually assigning link local addresses. It
is just that nobody wants to bother with that and you wouldn't either.

Example:

root@jump2:~# ip addr add fe80::1:/64 dev eth0
root@jump2:~# ping6 fe80::1:%eth0
PING fe80::1:%eth0(fe80::1:) 56 data bytes
64 bytes from fe80::1:: icmp_seq=1 ttl=64 time=0.033 ms



> ND is new thing and it requires new things to protect it from attacks?
>

I am not aware of any NDP attacks that would be any different if based on
ARP. Those two protocols are practically the same.

Regards,

Baldur

Re: IPv6 woes - RFC

[borg]

Because IPv4 loopback is 127.0.0.1/8 and its usefull?

0:0:1-:0/32 means you generate addreses from
that range and not necessary using /32 prefix..
It just range thats reserved for LL.

Same about RFC1918 aka space.. its a range reserved for local addreses.

The whole rationale is:
- shorter prefix wins (so no overlap?)
- you can use nice short addreses like ::1234 for loopback
  or ::1: for LL or ::1:0:1234 for RFC1918 like

Whole ::1 short format should be used only to cut leading zeros
not "more zeroes whatnever they appear".

ND is new thing and it requires new things to protect it from attacks?

While all the hate towards NAT, after years of using it I see it as cool
thing now. Yeah it breaks E2E, and thats why its place is only at CPE.
The true tragedy is CGN.

Yeah, services make money so they should addapt new protocol, so users
can access those services. In my opinion, due to IPv4 exhaustion, this
is right adoption scheme. You move users to IPv6 and free IPv4 addresses
for more services. It means internet can still grow and noone is really cut
off. Once IPv6 mass is big enough, you can start to fade IPv4 services.

Prototype yeah... if only this would 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 really happen (new protocol).
> Im not happy with IPv6, and it seems many others too.
> 
> This is short list how my ideal IPv6 proto looks like:
> - 64bit address space
>  more is not always better

Perhaps, but the benefits of a 128 bit address space with a convenient
near universal network/host boundary has benefits. What would be the
perceived benefit of 64-bit addressing over 128?

> - loopback 0:0:0:1/48

Why dedicate a /48 to loopback?

> - soft LL 0:0:1-:0/32 (Link Local)

Having trouble understanding that expression˙˙ Wouldn˙˙t it overlap loopback, 
since
0:0::/32 and 0:0:0::/48 would be overlapping prefixes?

> - RFC1918 address space 0:1-:0:0/16

Why repeat this mistake?

> - keep ARPs, ND wasnt great idea after all?

I don˙˙t see a significant difference (pro or con) to ND vs. ARP.

> - NAT support (because its everywhere these days)

That˙˙s a tragedy of IPv4, I don˙˙t see a benefit to inflicting it on a new 
protocol.

> - IPv6 -> IPv4 interop (oneway)
>  we can put customers on IPv6, while keeping services dualstack

That requires the services to be dual stack which is kind of the problem we have
with IPv6 today˙˙ Enough services that matter aren˙˙t dual stack.

> - correct DHCP support (SLAAC wasnt great idea after all?)
>  I think its already in IPv6, but was an issue at the begining

Depends on your definition of ˙˙correct˙˙. I disagree about SLAAC not being a 
great
idea. It might not fit every need, but it˙˙s certainly a low-overhead highly 
useful
mechanism in a lot of deployments.

> If there are some weird requirements from others, put them into layer up.
> L3 needs to be simple (KISS 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 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 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 dont disagree, but a reversion to IPv4-only certainly wont do it.
> 
> For everyone who does have enough IPv4 addresses, it does. This is the problem
> in a nutshell. If that starts trending, IPv6 is done.
> 
>> I think the only way out is through.
> 
> 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 rough.
> 
> And as the trip winds on, the landscape is changing, not necessarily for the
> better.
> 
> One more "any decade now" and another IPv4 replacement/extension might just
> happen on the scene and catch on, rendering IPv6 the most wasteful global
> technical debacle to date.
> 
> 
>>  Unfortunately, the IPv6 resistant forces
>> are making that hard for everyone else.
>> 
>> Owen
> 
> You say that as if it was a surprise, when it should not have been, and you 

Re: IPv6 woes - RFC

[borg]

Well, I think we should not compare IPX to IPv4 because those protocols
were made to handle completly different networks?

Yeah, IPv6 is new, but its more like revolution instead of evolution.

Well, Industry seems to addapt things quickly when they are good enough.
Better things replace worse. Of course its not always the case, sometimes
things are being forced here.. And thats how I feel about IPv6..

IPv4 Lookback is 127.0.0.1/8
You can use bind IPs within range by applications. Handy
In IPv6 its not the case.

IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
Tables overflows, attacks and DDoS.. Why to repeat history again?

IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some 
issues. If this is not the case, im sorry. Its been a while when I last time
played with IPv6...

IPv6 interop: yeah, I agree here.. But people involved with IPv6 should 
think about some external IPv4 interop.. Internet was exploding at 1997..
Maybe they had hope that everyone upgrade like in CIDR case. And maybe it 
could happen if IPv6 wasnt so alien ;)

As for IPv4 vs IPv6 complexity, again, why repeat history. Biggest IPv4
mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
(Another big mistake was class E reservation...)
Internet was tiny at that time so everyone followed.
Image something like this today? Same about IPv6.. it brings
forced network::endpoint probably due to IoT, sacrificing flexibility.

Again, I dont want to really 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:
> 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 greater than the delta
between IPv4 and IPX?

If anything, I think the delta between IPv4 and IPv6 is too small. Small enough
that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction
between the multiple personalities therein.  I also think that the grouping of
IPv4 and IPv6 as one protocol is part of the downfall.

More over if you think of IPv4 and IPv6 dual stack as analogous to the
multi-protocol networks of the '90s, and treat them as disparate protocols that
serve similar purposes in (completely) different ways, a lot of the friction
seems to make sense and as such becomes less friction through understanding and
having reasonable expectations for the disparate protocols.

> 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.

I don't think you truly mean that having a new protocol is fine. Because if you
did, I think you would treat IPv6 as a completely different protocol from IPv4.
E.g. AppleTalk vs DECnet.  After all, we effectively do have a new protocol;
IPv6.

IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98.  Or
"different" in place of "similar".

> It should just fix problem (do we have other problems I am not aware of with
> IPv4?) of address space and thats it.  Im happy with IPv4, after 30+ years of
> usage we pretty much fixed all problems we had.

I disagree.

> The second failure is adoption. Even if my IPv6 hate is not rational, adoption
> of IPv6 is crap. If adoption would be much better, more IPv4 could be used for
> legacy networks ;) So stuborn guys like me could be happy too ;)

I blame the industry, not the IPv6 protocol, for the lackluster adoption of
IPv6.

> As for details, that list is just my dream IPv6 protocol ;)
> 
> But lets talk about details:
> - Loopback on IPv6 is ::1/128
>I have setups where I need more addresses there that are local only.
>Yeah I know, we can put extra aliases on interfaces etc.. but its extra
>work and not w/o problems

How does IPv6 differ from IPv4 in this context?

> - IPv6 Link Local is forced.
>I mean, its always on interface, nevermind you assign static IP.
>LL is still there and gets in the way (OSPFv3... hell yeah)

I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do
on a network.  But I don't see a technical problem with this in and of itself.
--  I can't speak to OSPFv3 issues.

> - ULA space, well.. its like RFC1918 but there are some issues with it
>(or at least was? maybe its fixed) like source IP selection on with
>multiple addresses.

I consider this to be implementation issues and not a problem with the protocol
itself.

> - Neighbor Discovery protocol... quite a bit problems it created.

Please elaborate.

>What was wrong w/ good old AR

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

iled. There are probably multiple reasons for it.
> Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4
> works for me for now.

Many of us have moved to IPv6 and for eyeball sites that have deployed it,
more than 50% of most traffic flows over IPv6.

I think its telling that India is at roughly 97% IPv6 deployment. By the
time internet was developing in India, APNIC was mostly out of addresses.
This coupled with the previous regulatory environment for internet services
in India severely crippled India’s access to iPv4 addresses.

I know of multiple enterprises in the US that are now deploying IPv6 at
least at their edge in order to work with developers in India.

India is a microcosm of what is to come in the developing world.

The US is at roughly 47% IPv6 eyeballs preferred today. There is going
to come a time when we start having IPv6-only eyeballs in the US and
other parts of the world. How painful or problematic that becomes will
depend on a large extent 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: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 protocol?
> 
> I think that it's a very critical distinction.  Much like DoH as a protocol vs
> how some companies have chosen to utilize it.  Similar to IBM's computers vs
> what they were used for in the 1940's.
> 
>> This is short list how my ideal IPv6 proto looks like:
>> - 64bit address space
>>   more is not always better
>> - loopback 0:0:0:1/48
>> - soft LL 0:0:1-:0/32 (Link Local)
>> - RFC1918 address space 0:1-:0:0/16
>> - keep ARPs, ND wasnt great idea after all?
>> - NAT support (because its everywhere these days)
>> - IPv6 -> IPv4 interop (oneway)
>>   we can put customers on IPv6, while keeping services dualstack
>> - correct DHCP support (SLAAC wasnt great idea after all?)
>>   I think its already in IPv6, but was an issue at the begining
> 
> I'm probably showing my ignorance, but I believe that the IPv6 that we have
> today effectively does all of those things.  At least functionality, perhaps
> with different values.
> 
>> If there are some weird requirements from others, put them into layer up.
>> L3 needs to be simple (KISS concept), so its easy to implement and less
>> prone to bugs.
> 
> How many of the hurtles to IPv6's deployment have been bugs in layer 3? It 
> seems
> to me that most of the problems with IPv6 that I'm aware of are at other 
> layers,
> significantly higher in, or on top of, the stack.
> 
>> And that IPv6 I would love to see and addapt right away :)
> 
> I'm of the opinion that IPv6 has worked quite well dual stack from about
> 2005-2015.  It's only been in the last 5 or so years that I'm starting to see
> more problems with IPv6.  And all of the problems that I'm seeing are 
> companies
> making business level decisions, way above layer 7, that negatively impact 
> IPv6.
> Reluctance to run an MX on IPv6 for business level decisions is definitely 
> not a
> protocol, much less L3, problem.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 possibility 
>>> we will never quite reach it, and the potholes on the way are pretty rough.
>> By “the only way out is through” I meant that the only way we can get back 
>> to anything resembling mono-stack is, in fact, to complete the transition to 
>> IPv6.
> 
> The question is how? Waiting for everyone or nearly everyone to dual stack, 
> the current strategy, is awful. Like pulling gum off a shoe.

Agreed, so the question boils down to what can be done to motivate the laggard 
content providers to get off the dime.

>>> And as the trip winds on, the landscape is changing, not necessarily for 
>>> the better.
>> The IPv4 landscape will continue to get worse and worse. It cannot possibly 
>> get better, there just aren’t enough addresses for that.
> 
> I was referring to the more general network landscape, the governance system, 
> the end of p2p, balkanization, etc, all trends and shifts that become more 
> likely and entrenched the longer IPv6 lags and the scarcer IPv4 becomes.
> 
>> 
>>> One more "any decade now" and another IPv4 replacement/extension might just 
>>> happen on the scene and catch on, rendering IPv6 the most wasteful global 
>>> technical debacle to date.
>> If that’s what it takes to move forward with a protocol that has enough 
>> addresses, then so be it. I’m not attached to IPv6 particularly, but I 
>> recognize that IPv4 can’t keep up. As such, IPv6 is just the best current 
>> candidate. If someone offers a better choice, I’m all for it.
> 
> Whose to say it would be a proper p2p system? I know you believe strongly in 
> that and want it fully restored, at least on the protocol level.

There are so many potential useful things we could do with a restored e2e 
system that are simply not proactical today that yes, I consider that vital.

For one thing, I’m really tired of vendor cloud locking just because products 
need rendezvous hosts with public addresses.

  Unfortunately, the IPv6 resistant forces
 are making that hard for everyone else.
 
 Owen
>>> You say that as if it was a surprise, when it should not have been, and you 
>>> say that as if something can be done about it, which we should know by now 
>>> cannot be the primary focus, since it cannot be done in any timely fashion. 
>>> If at all.
>> It’s not a surprise, but it is a tragedy.
>> 
>> There are things that can be done about it, but nobody currently wants to do 
>> them.
> 
> So lets make the conversation revolve around what can be done to actually 
> advance IPv6, and what we should know by now is that convincing or coercing 
> deployment with the current state of affairs does not have enough horsepower 
> to get IPv6 anywhere far anytime soon.

I’m open to alternatives if you have any to offer.

>>> Its time to throw mud on the wall and see what sticks. Dual stack and wait 
>>> is an ongoing failure slouching to disaster.
>> IPv4 is an ongoing failure slouching to disaster, but the IPv6-resistant 
>> among us remain in denial about that.
> 
> Who is this "us"? Anybody even discussing IPv6 in a public forum is well 
> ahead of the curve. Unfortunately. All early adopters. Real Early.

Everybody using the internet, but more importantly, the content providers that 
are resisting IPv6 deployment on their content are probably the biggest problem 
at this time.

>> At some point, we are going to have to make a choice about how much longer 
>> we want to keep letting them hold us back. It will not be an easy choice, it 
>> will not be convenient, and it will not be simple.
>> 
>> The question is how much more pain an dhow much longer will it take before 
>> the choice becomes less difficult than the wait?
>> 
>> Owen
>> 
> Exactly what does this choice look like? Turn off IPv4 when its fully 
> functional? Only the have-nots may make the choice not to deploy IPv4 
> sometime in the future, and for them, its not going to be a real choice.

IPv4 hasn’t been fully functional for more than a decade. At some point, the 
pain of continuing to wait for the laggards will become sufficient that those 
who have been running dual-stack will simply turn off IPv4 and leave the 
laggards behind. It might tragically not happen in my lifetime, but it has to 
happen at some point.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 24, 2021, at 2: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.
> 
> This is short list how my ideal IPv6 proto looks like:
> - 64bit address space
>  more is not always better

Perhaps, but the benefits of a 128 bit address space with a convenient
near universal network/host boundary has benefits. What would be the
perceived benefit of 64-bit addressing over 128?

> - loopback 0:0:0:1/48

Why dedicate a /48 to loopback?

> - soft LL 0:0:1-:0/32 (Link Local)

Having trouble understanding that expression… Wouldn’t it overlap loopback, 
since
0:0::/32 and 0:0:0::/48 would be overlapping prefixes?

> - RFC1918 address space 0:1-:0:0/16

Why repeat this mistake?

> - keep ARPs, ND wasnt great idea after all?

I don’t see a significant difference (pro or con) to ND vs. ARP.

> - NAT support (because its everywhere these days)

That’s a tragedy of IPv4, I don’t see a benefit to inflicting it on a new 
protocol.

> - IPv6 -> IPv4 interop (oneway)
>  we can put customers on IPv6, while keeping services dualstack

That requires the services to be dual stack which is kind of the problem we have
with IPv6 today… Enough services that matter aren’t dual stack.

> - correct DHCP support (SLAAC wasnt great idea after all?)
>  I think its already in IPv6, but was an issue at the begining

Depends on your definition of “correct”. I disagree about SLAAC not being a 
great
idea. It might not fit every need, but it’s certainly a low-overhead highly 
useful
mechanism in a lot of deployments.

> If there are some weird requirements from others, put them into layer up.
> L3 needs to be simple (KISS 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 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 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 dont disagree, but a reversion to IPv4-only certainly wont do it.
> 
> For everyone who does have enough IPv4 addresses, it does. This is the problem
> in a nutshell. If that starts trending, IPv6 is done.
> 
>> I think the only way out is through.
> 
> 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 rough.
> 
> And as the trip winds on, the landscape is changing, not necessarily for the
> better.
> 
> One more "any decade now" and another IPv4 replacement/extension might just
> happen on the scene and catch on, rendering IPv6 the most wasteful global
> technical debacle to date.
> 
> 
>>  Unfortunately, the IPv6 resistant forces
>> are making that hard for everyone else.
>> 
>> Owen
> 
> You say that as if it was a surprise, when it should not have been, and you 
> say
> that as if something can be done about it, which we should know by now cannot 
> be
> the primary focus, since it cannot be done in any timely fashion. If at all.
> 
> Its time to throw mud on the wall and see what sticks. Dual stack and wait is 
> an
> ongoing failure slouching to disaster.
> 
> Joe
> 
> 
> 
> 

Re: IPv6 woes - RFC

[Joe Maimon]

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 option as one concept that was shot 
down in favor of a new protocol.


If it was just an incremental IPv4 upgrade, than we would have been 
there already, and you could be using your extended IPv4 addresses to 
communicate with any gear over any network gear that had been upgraded 
in the past decade or two.


Its just that the internet was supposed to be able deploy a new protocol 
in the same or less time. Which didnt happen.


Joe

Re: IPv6 woes - RFC

[Grant Taylor via NANOG]

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 greater than 
the delta between IPv4 and IPX?


If anything, I think the delta between IPv4 and IPv6 is too small. 
Small enough that both IPv4 and IPv6 get treated as one protocol and 
thus a lot of friction between the multiple personalities therein.  I 
also think that the grouping of IPv4 and IPv6 as one protocol is part of 
the downfall.


More over if you think of IPv4 and IPv6 dual stack as analogous to the 
multi-protocol networks of the '90s, and treat them as disparate 
protocols that serve similar purposes in (completely) different ways, a 
lot of the friction seems to make sense and as such becomes less 
friction through understanding and having reasonable expectations for 
the disparate protocols.


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.


I don't think you truly mean that having a new protocol is fine. 
Because if you did, I think you would treat IPv6 as a completely 
different protocol from IPv4.  E.g. AppleTalk vs DECnet.  After all, we 
effectively do have a new protocol; IPv6.


IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98.  Or 
"different" in place of "similar".


It should just fix problem (do we have other problems I am not aware 
of with IPv4?) of address space and thats it.  Im happy with IPv4, 
after 30+ years of usage we pretty much fixed all problems we had.


I disagree.

The second failure is adoption. Even if my IPv6 hate is not rational, 
adoption of IPv6 is crap. If adoption would be much better, more IPv4 
could be used for legacy networks ;) So stuborn guys like me could 
be happy too ;)


I blame the industry, not the IPv6 protocol, for the lackluster adoption 
of IPv6.



As for details, that list is just my dream IPv6 protocol ;)

But lets talk about details:
- Loopback on IPv6 is ::1/128
   I have setups where I need more addresses there that are local only.
   Yeah I know, we can put extra aliases on interfaces etc.. but its extra
   work and not w/o problems


How does IPv6 differ from IPv4 in this context?


- IPv6 Link Local is forced.
   I mean, its always on interface, nevermind you assign static IP.
   LL is still there and gets in the way (OSPFv3... hell yeah)


I agree that IPv6 addresses seem to accumulate on interfaces like IoT 
devices do on a network.  But I don't see a technical problem with this 
in and of itself.  --  I can't speak to OSPFv3 issues.



- ULA space, well.. its like RFC1918 but there are some issues with it
   (or at least was? maybe its fixed) like source IP selection on with
   multiple addresses.


I consider this to be implementation issues and not a problem with the 
protocol itself.



- Neighbor Discovery protocol... quite a bit problems it created.


Please elaborate.


   What was wrong w/ good old ARP? I tought we fixed all those problems
   already like ARP poisoning via port security.. etc


The apparent need to ""fix / address / respond to a protocol problem at 
a lower layer seems like a problem to me.



- NAT is there in IPv6 so no futher comments
- DHCP start to get working on IPv6.. but it still pain sometimes


What problems do you have with DHCP for IPv6?  I've been using it for 
the better part of a decade without any known problems.  What pain are 
you experiencing?



And biggest problem, interop w/ IPv4 was completly failure.


I agree that the interoperability between IPv4 and IPv6 is the tall pole 
in the tent.  But I also believe that's to be expected when trying to 
interoperate disparate protocols.


From ground zero, I would expect that disparate protocols can't 
interoperate without external support, some of which requires explicit 
configuration.


Currently we have best Internet to migrate to new protocol. 
Why?


The primary motivation -- as I understand it -- is the lack of unique IP 
addresses.


Because how internet become centralized. Eyeball networks just 
want to reach content. E2E communication is not that much needed. 
We have games and enhusiast, but those can pay extra for public IPv4. 
Or get VPN/VPS.


Now you are talking about two classes of Internet connectivity:

1)  First class participation where an endpoint /is/ /on/ the Internet 
with a globally routed IP.
2)  Second class participation where an endpoint /has/ /access/ /to/ the 
Internet via a non-globally routed IP.


There may be some merit to multiple classes of Internet connectivity. 
But I think it should be dealt with openly and above board as such.


And end comment. I do NOT want to start some kind of flame war here. 
Yeah I know, Im biased toward IPv4.


I don't view honest and good spirited discussion of 

Re: IPv6 woes - RFC

[Michael Thomas]

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 fix problem (do we have other
problems I am not aware of with IPv4?) of address space and thats it.
Im happy with IPv4, after 30+ years of usage we pretty much fixed all
problems we had.

But that is what ipv6 delivers -- a 64 bit routing prefix. Am I to take 
it that a whopping 16 bytes of extra addressing information breaks the 
internet? And all of the second system syndrome stuff was always 
separable just like any other IETF protocol. you implement what is 
needed and ignore all of the rest -- there is no IETF police after all.


I can understand the sound and fury when people were trying to make this 
work on 56kb modems, but with speeds well over 1G it seems sort of archaic.


Mike

Re: IPv6 woes - RFC

[borg]

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 fix problem (do we have other
problems I am not aware of with IPv4?) of address space and thats it.
Im happy with IPv4, after 30+ years of usage we pretty much fixed all 
problems we had.

The second failure is adoption. Even if my IPv6 hate is not rational,
adoption of IPv6 is crap. If adoption would be much better, more IPv4
could be used for legacy networks ;) So stuborn guys like me could be happy 
too ;)

As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details:
- Loopback on IPv6 is ::1/128
  I have setups where I need more addresses there that are local only.
  Yeah I know, we can put extra aliases on interfaces etc.. but its extra
  work and not w/o problems
- IPv6 Link Local is forced.
  I mean, its always on interface, nevermind you assign static IP.
  LL is still there and gets in the way (OSPFv3... hell yeah)
- ULA space, well.. its like RFC1918 but there are some issues with it
  (or at least was? maybe its fixed) like source IP selection on with 
  multiple addresses.
- Neighbor Discovery protocol... quite a bit problems it created.
  What was wrong w/ good old ARP? I tought we fixed all those problems
  already like ARP poisoning via port security.. etc
- NAT is there in IPv6 so no futher comments
- DHCP start to get working on IPv6.. but it still pain sometimes

And biggest problem, interop w/ IPv4 was completly failure.
Currently we have best Internet to migrate to new protocol.
Why? Because how internet become centralized. Eyeball networks
just want to reach content. E2E communication is not that much needed.
We have games and enhusiast, but those can pay extra for public IPv4.
Or get VPN/VPS.

And end comment. I do NOT want to start some kind of flame war here.
Yeah I know, Im biased toward IPv4. If something new popups, I want it 
better than previous thingie (a lot) and easier or at least same level of 
complications, but IPv6 just solves one thing and brings a lot of 
complexity.

The fact is, IPv6 failed. There are probably multiple reasons for it.
Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4
works for me for now.


-- 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 seems many others too.

Is your dissatisfaction with the IPv6 protocol itself or is your dissatisfaction
with the deployment / adoption of the IPv6 protocol?

I think that it's a very critical distinction.  Much like DoH as a protocol vs
how some companies have chosen to utilize it.  Similar to IBM's computers vs
what they were used for in the 1940's.

> This is short list how my ideal IPv6 proto looks like:
> - 64bit address space
>more is not always better
> - loopback 0:0:0:1/48
> - soft LL 0:0:1-:0/32 (Link Local)
> - RFC1918 address space 0:1-:0:0/16
> - keep ARPs, ND wasnt great idea after all?
> - NAT support (because its everywhere these days)
> - IPv6 -> IPv4 interop (oneway)
>we can put customers on IPv6, while keeping services dualstack
> - correct DHCP support (SLAAC wasnt great idea after all?)
>I think its already in IPv6, but was an issue at the begining

I'm probably showing my ignorance, but I believe that the IPv6 that we have
today effectively does all of those things.  At least functionality, perhaps
with different values.

> If there are some weird requirements from others, put them into layer up.
> L3 needs to be simple (KISS concept), so its easy to implement and less
> prone to bugs.

How many of the hurtles to IPv6's deployment have been bugs in layer 3? It seems
to me that most of the problems with IPv6 that I'm aware of are at other layers,
significantly higher in, or on top of, the stack.

> And that IPv6 I would love to see and addapt right away :)

I'm of the opinion that IPv6 has worked quite well dual stack from about
2005-2015.  It's only been in the last 5 or so years that I'm starting to see
more problems with IPv6.  And all of the problems that I'm seeing are companies
making business level decisions, way above layer 7, that negatively impact IPv6.
Reluctance to run an MX on IPv6 for business level decisions is definitely not a
protocol, much less L3, problem.



-- 
Grant. . . .
unix || die

Re: IPv6 woes - RFC

[Joe Maimon]

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 rough.

By “the only way out is through” I meant that the only way we can get back to 
anything resembling mono-stack is, in fact, to complete the transition to IPv6.


The question is how? Waiting for everyone or nearly everyone to dual 
stack, the current strategy, is awful. Like pulling gum off a shoe.





And as the trip winds on, the landscape is changing, not necessarily for the 
better.

The IPv4 landscape will continue to get worse and worse. It cannot possibly get 
better, there just aren’t enough addresses for that.


I was referring to the more general network landscape, the governance 
system, the end of p2p, balkanization, etc, all trends and shifts that 
become more likely and entrenched the longer IPv6 lags and the scarcer 
IPv4 becomes.





One more "any decade now" and another IPv4 replacement/extension might just 
happen on the scene and catch on, rendering IPv6 the most wasteful global technical 
debacle to date.

If that’s what it takes to move forward with a protocol that has enough 
addresses, then so be it. I’m not attached to IPv6 particularly, but I 
recognize that IPv4 can’t keep up. As such, IPv6 is just the best current 
candidate. If someone offers a better choice, I’m all for it.


Whose to say it would be a proper p2p system? I know you believe 
strongly in that and want it fully restored, at least on the protocol level.



  Unfortunately, the IPv6 resistant forces
are making that hard for everyone else.

Owen

You say that as if it was a surprise, when it should not have been, and you say 
that as if something can be done about it, which we should know by now cannot 
be the primary focus, since it cannot be done in any timely fashion. If at all.

It’s not a surprise, but it is a tragedy.

There are things that can be done about it, but nobody currently wants to do 
them.


So lets make the conversation revolve around what can be done to 
actually advance IPv6, and what we should know by now is that convincing 
or coercing deployment with the current state of affairs does not have 
enough horsepower to get IPv6 anywhere far anytime soon.





Its time to throw mud on the wall and see what sticks. Dual stack and wait is 
an ongoing failure slouching to disaster.

IPv4 is an ongoing failure slouching to disaster, but the IPv6-resistant among 
us remain in denial about that.


Who is this "us"? Anybody even discussing IPv6 in a public forum is well 
ahead of the curve. Unfortunately. All early adopters. Real Early.


At some point, we are going to have to make a choice about how much longer we 
want to keep letting them hold us back. It will not be an easy choice, it will 
not be convenient, and it will not be simple.

The question is how much more pain an dhow much longer will it take before the 
choice becomes less difficult than the wait?

Owen

Exactly what does this choice look like? Turn off IPv4 when its fully 
functional? Only the have-nots may make the choice not to deploy IPv4 
sometime in the future, and for them, its not going to be a real choice.



Joe

Re: IPv6 woes - RFC

[Grant Taylor via NANOG]

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 protocol?


I think that it's a very critical distinction.  Much like DoH as a 
protocol vs how some companies have chosen to utilize it.  Similar to 
IBM's computers vs what they were used for in the 1940's.



This is short list how my ideal IPv6 proto looks like:
- 64bit address space
   more is not always better
- loopback 0:0:0:1/48
- soft LL 0:0:1-:0/32 (Link Local)
- RFC1918 address space 0:1-:0:0/16
- keep ARPs, ND wasnt great idea after all?
- NAT support (because its everywhere these days)
- IPv6 -> IPv4 interop (oneway)
   we can put customers on IPv6, while keeping services dualstack
- correct DHCP support (SLAAC wasnt great idea after all?)
   I think its already in IPv6, but was an issue at the begining


I'm probably showing my ignorance, but I believe that the IPv6 that we 
have today effectively does all of those things.  At least 
functionality, perhaps with different values.



If there are some weird requirements from others, put them into layer up.
L3 needs to be simple (KISS concept), so its easy to implement and less
prone to bugs.


How many of the hurtles to IPv6's deployment have been bugs in layer 3? 
It seems to me that most of the problems with IPv6 that I'm aware of are 
at other layers, significantly higher in, or on top of, the stack.



And that IPv6 I would love to see and addapt right away :)


I'm of the opinion that IPv6 has worked quite well dual stack from about 
2005-2015.  It's only been in the last 5 or so years that I'm starting 
to see more problems with IPv6.  And all of the problems that I'm seeing 
are companies making business level decisions, way above layer 7, that 
negatively impact IPv6.  Reluctance to run an MX on IPv6 for business 
level decisions is definitely not a protocol, much less L3, problem.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: IPv6 woes - RFC

[borg]

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.

This is short list how my ideal IPv6 proto looks like:
- 64bit address space
  more is not always better
- loopback 0:0:0:1/48
- soft LL 0:0:1-:0/32 (Link Local)
- RFC1918 address space 0:1-:0:0/16
- keep ARPs, ND wasnt great idea after all?
- NAT support (because its everywhere these days)
- IPv6 -> IPv4 interop (oneway)
  we can put customers on IPv6, while keeping services dualstack
- correct DHCP support (SLAAC wasnt great idea after all?)
  I think its already in IPv6, but was an issue at the begining

If there are some weird requirements from others, put them into layer up.
L3 needs to be simple (KISS concept), so its easy to implement and less
prone to bugs.

And that IPv6 I would love to see and addapt right away :)


-- Original 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 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 dont disagree, but a reversion to IPv4-only certainly wont do it.

For everyone who does have enough IPv4 addresses, it does. This is the problem
in a nutshell. If that starts trending, IPv6 is done.

> I think the only way out is through.

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 rough.

And as the trip winds on, the landscape is changing, not necessarily for the
better.

One more "any decade now" and another IPv4 replacement/extension might just
happen on the scene and catch on, rendering IPv6 the most wasteful global
technical debacle to date.


>   Unfortunately, the IPv6 resistant forces
> are making that hard for everyone else.
> 
> Owen

You say that as if it was a surprise, when it should not have been, and you say
that as if something can be done about it, which we should know by now cannot be
the primary focus, since it cannot be done in any timely fashion. If at all.

Its time to throw mud on the wall and see what sticks. Dual stack and wait is an
ongoing failure slouching to disaster.

Joe

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 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 gurus), not to mention some 
>>> business applications that would break or be sub-optimal at best. I see CGN 
>>> as the band aid to this issue, not the cure to the problem.
>> 
>> Today? no.
>> 
>> At some point when a relatively small number of remaining laggards among 
>> major content providers move forward? Yes.
> 
> So do we just bleed out in the mean time?

Well, you can turn off IPv4 on your network whenever you choose to do so.

Unfortunately, I suspect you’re in the same boat I am there, yes, continuing to 
bleed until the laggards on the content side get their acts together.

>> Do you really think that those applications/vendors wouldn’t move quickly if 
>> a couple of major eyeball providers announced “Effective X date”, we’re 
>> going to start offering a $X/month discount to any customer(s) who are 
>> willing to stop using IPv4.
> 
> I’d be happy to suggest this to my clients, but it’s not a real thing yet. 
> Plus, the average human (even the average CSR at a small regional provider 
> network) has no idea what this means.

Yeah, it doesn’t mean anything there. For it to mean something, it would have 
to be somebody like Comcast, Cox, etc. and they’d have to put it like 2 years 
out, but make a big point of it with the content providers.

Another thing they could do if so inclined (the really big eyeball providers) 
is they could start doing settlement free IPv6-only PNIs for content providers.

>> You an only cover an arterial bleed with a band-aid for so long before it 
>> becomes silly, septic even. If you’re wondering how quick that point is 
>> coming up, I suggest you check your mirrors.
> 
> Triage suggests that you assist in succession of the current bleeding before 
> being concerned about the next time you are cut. I have BGN deployments that 
> have been in place for 4+ years with little customer knowledge. It has 
> allowed clients to avoid the IPv4 market issues, and in some instances, 
> become a source for others to help compensate for the initial CGN expense.

I hear you. I’m not sure there’s a viable alternative, but in my experience, 
CGN pisses off online gamers something fierce and if you’re an eyeball ISP, I 
don’t envy you the phone calls that’s going to create, especially as games get 
more and more network-oriented.

Sony already categorizes NAT into various categories and basically when it 
detects CGN it can’t easily penetrate or circumvent, it tells you to call your 
ISP and complain.

> I totally agree with you in spirit, but I am working on the problem of now, 
> not the problem of some point in the future. The cost of CGN is becoming less 
> expensive than IPv4 space acquisition. I wish this weren’t true.

Yeah, but it’s far from zero and that’s more because IPv4 is getting more 
expensive than because CGN is getting cheaper.

There’s only so far you can go with CGN before the user experience turns 
universally bad. It turns bad for a lot of customers well before that point.

I don’t envy you.

Owen

> 
>> 
>> Owen
>> 
>>> 
>>> Discuss…?
>>> 
>>> - Brian
>>> 
 On Sep 23, 2021, at 10:46 AM, 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 certainly won’t do it.
 
 I think the only way out is through. Unfortunately, the IPv6 resistant 
 forces
 are making that hard for everyone else.
 
 Owen
 
>>> 
>> 
> 

Re: IPv6 woes - RFC

[John Levine]

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

[Christopher Morrow]

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/port/proto
>>
>
> What you describe is called symmetric NAT and is the kind which has the
> highest impact on customers. Many NAT traversal techniques fail to work
> with this type of NAT. STUN does not work with symmetric NAT.
>
>
why. (does stun/etc not work, I mean)
Is the answer: "Because to do it right you need an ALG and that's more
costly/problematic."
or is the answer some other thing?


> You purposely want a lesser NAT type which makes NAT traversal easy. This
> enables more applications to function despite the NAT. Almost every CPE
> avoids symmetric NAT for one of the lesser types for this reason.
>
>

>> unless some internal/original src is double using port/proto ... you
>> should really
>> have the ability to nat quite a large number of things to a single ipv4
>> address.
>>
>
> There is no point in optimizing your customer per public CGN IP address
> ratio and multiple reasons for not doing so. At some point you will
> experience attacks on the CGN address or blacklisting in online games and
> so on. Having less customers affected each time that happens is better.
>
>
Sorry, my point wasn't: "Oh you should just 1 address!"
For many reasons that's crazy sauce.

I was just pointing out that you'd be ABLE TO, if you wanted, sure more ips
is better though.
mostly the '100 ports per backend address' isn't really correct, if you are
smarter in the nat state management.

In our network approximately 10% of new customers signed up within the last
> year have asked to escape the CGN and get a public IP. This means I need
> 100 IPv4 addresses per 1000 new customers. Plus 4 IPv4 addresses for the
> CGN server. What difference would it make if we could optimize those 4
> addresses to be just 2 or maybe 1? What if it caused just a couple more
> customers to request a public IP address because they got annoyed by a more
> restrictive NAT or by failed sessions?
>
> Regards,
>
> Baldur
>
>

Re: IPv6 woes - RFC

[Brian Johnson]

> 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 with that? I 
>> believe that there are several applications used by some of the the loudest 
>> customers (typically gamers and network gurus), not to mention some business 
>> applications that would break or be sub-optimal at best. I see CGN as the 
>> band aid to this issue, not the cure to the problem.
> 
> Today? no.
> 
> At some point when a relatively small number of remaining laggards among 
> major content providers move forward? Yes.

So do we just bleed out in the mean time?

> 
> Do you really think that those applications/vendors wouldn’t move quickly if 
> a couple of major eyeball providers announced “Effective X date”, we’re going 
> to start offering a $X/month discount to any customer(s) who are willing to 
> stop using IPv4.

I’d be happy to suggest this to my clients, but it’s not a real thing yet. 
Plus, the average human (even the average CSR at a small regional provider 
network) has no idea what this means.

> 
> You an only cover an arterial bleed with a band-aid for so long before it 
> becomes silly, septic even. If you’re wondering how quick that point is 
> coming up, I suggest you check your mirrors.

Triage suggests that you assist in succession of the current bleeding before 
being concerned about the next time you are cut. I have BGN deployments that 
have been in place for 4+ years with little customer knowledge. It has allowed 
clients to avoid the IPv4 market issues, and in some instances, become a source 
for others to help compensate for the initial CGN expense.

I totally agree with you in spirit, but I am working on the problem of now, not 
the problem of some point in the future. The cost of CGN is becoming less 
expensive than IPv4 space acquisition. I wish this weren’t true.

> 
> Owen
> 
>> 
>> Discuss…?
>> 
>> - Brian
>> 
>>> On Sep 23, 2021, at 10:46 AM, 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 certainly won’t do it.
>>> 
>>> I think the only way out is through. Unfortunately, the IPv6 resistant 
>>> forces
>>> are making that hard for everyone else.
>>> 
>>> Owen
>>> 
>> 
> 

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 of dual-stack-hell.
>> I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
> 
> For everyone who does have enough IPv4 addresses, it does. This is the 
> problem in a nutshell. If that starts trending, IPv6 is done

This is virtually no-one with any growth. That’s why Azure, AWS, and Google 
have been snapping up every large prefix that comes on
the market as fast as they can. I don’t see how this can possibly trend long 
enough to matter before it hits that brick wall.
.
>> I think the only way out is through.
> 
> 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 rough.

By “the only way out is through” I meant that the only way we can get back to 
anything resembling mono-stack is, in fact, to complete the transition to IPv6.

> And as the trip winds on, the landscape is changing, not necessarily for the 
> better.

The IPv4 landscape will continue to get worse and worse. It cannot possibly get 
better, there just aren’t enough addresses for that.

> One more "any decade now" and another IPv4 replacement/extension might just 
> happen on the scene and catch on, rendering IPv6 the most wasteful global 
> technical debacle to date.

If that’s what it takes to move forward with a protocol that has enough 
addresses, then so be it. I’m not attached to IPv6 particularly, but I 
recognize that IPv4 can’t keep up. As such, IPv6 is just the best current 
candidate. If someone offers a better choice, I’m all for it.

>>  Unfortunately, the IPv6 resistant forces
>> are making that hard for everyone else.
>> 
>> Owen
> 
> You say that as if it was a surprise, when it should not have been, and you 
> say that as if something can be done about it, which we should know by now 
> cannot be the primary focus, since it cannot be done in any timely fashion. 
> If at all.

It’s not a surprise, but it is a tragedy.

There are things that can be done about it, but nobody currently wants to do 
them.

> Its time to throw mud on the wall and see what sticks. Dual stack and wait is 
> an ongoing failure slouching to disaster.

IPv4 is an ongoing failure slouching to disaster, but the IPv6-resistant among 
us remain in denial about that.

At some point, we are going to have to make a choice about how much longer we 
want to keep letting them hold us back. It will not be an easy choice, it will 
not be convenient, and it will not be simple.

The question is how much more pain an dhow much longer will it take before the 
choice becomes less difficult than the wait?

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 some of the the loudest customers 
> (typically gamers and network gurus), not to mention some business 
> applications that would break or be sub-optimal at best. I see CGN as the 
> band aid to this issue, not the cure to the problem.

Today? no.

At some point when a relatively small number of remaining laggards among major 
content providers move forward? Yes.

Do you really think that those applications/vendors wouldn’t move quickly if a 
couple of major eyeball providers announced “Effective X date”, we’re going to 
start offering a $X/month discount to any customer(s) who are willing to stop 
using IPv4.

You an only cover an arterial bleed with a band-aid for so long before it 
becomes silly, septic even. If you’re wondering how quick that point is coming 
up, I suggest you check your mirrors.

Owen

> 
> Discuss…?
> 
> - Brian
> 
>> On Sep 23, 2021, at 10:46 AM, 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 certainly won’t do it.
>> 
>> I think the only way out is through. Unfortunately, the IPv6 resistant forces
>> are making that hard for everyone else.
>> 
>> Owen
>> 
> 

Re: IPv6 woes - RFC

[Mark Andrews]

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, 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 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
>>> 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 16:48, Masataka Ohta 
  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 on a CGN. If 
 you try to go further than that, for example by using symmetric NAT, you 
 will increase the number of customers that want to get a public IPv4 of 
 their own. That will actually decrease the combined efficiency and cause 
 you to need more, not less, IPv4 addresses.
 
 Without checking our numbers, I believe we have at least 10% of the 
 customers that are paying for a public IPv4 to escape our CGN. This means 
 a /24 will only be enough for about 2500 customers maximum. The "nat 
 escapers" drown out the efficiency of the NAT pool.
 
 The optimization you need to do is to make the CGN as customer friendly as 
 possible instead of trying to squeeze the maximum customers per CGN IPv4 
 address.
 
 Perhaps IPv6 can lower the number of people that need to escape IPv4 nat. 
 If it helps just a little bit, that alone will make implementing IPv6 
 worth it for smaller emerging operators. Buying IPv4 has become very 
 expensive. Yes you can profit from selling a public IPv4 address to the 
 customer, but there is also the risk that the customer just goes to the 
 incumbent, which has old large pools of IPv4 and provides it for free.
 
 Regards,
 
 Baldur
 
>> 
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: IPv6 woes - RFC

[Joe Maimon]

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 certainly won’t do it.


For everyone who does have enough IPv4 addresses, it does. This is the 
problem in a nutshell. If that starts trending, IPv6 is done.



I think the only way out is through.


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 rough.


And as the trip winds on, the landscape is changing, not necessarily for 
the better.


One more "any decade now" and another IPv4 replacement/extension might 
just happen on the scene and catch on, rendering IPv6 the most wasteful 
global technical debacle to date.




  Unfortunately, the IPv6 resistant forces
are making that hard for everyone else.

Owen


You say that as if it was a surprise, when it should not have been, and 
you say that as if something can be done about it, which we should know 
by now cannot be the primary focus, since it cannot be done in any 
timely fashion. If at all.


Its time to throw mud on the wall and see what sticks. Dual stack and 
wait is an ongoing failure slouching to disaster.


Joe

Re: IPv6 woes - RFC

[Eric Kuhnke]

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 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
> > > 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 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 on a
> CGN. If you try to go further than that, for example by using symmetric
> NAT, you will increase the number of customers that want to get a public
> IPv4 of their own. That will actually decrease the combined efficiency and
> cause you to need more, not less, IPv4 addresses.
> > >>
> > >> Without checking our numbers, I believe we have at least 10% of the
> customers that are paying for a public IPv4 to escape our CGN. This means a
> /24 will only be enough for about 2500 customers maximum. The "nat
> escapers" drown out the efficiency of the NAT pool.
> > >>
> > >> The optimization you need to do is to make the CGN as customer
> friendly as possible instead of trying to squeeze the maximum customers per
> CGN IPv4 address.
> > >>
> > >> Perhaps IPv6 can lower the number of people that need to escape IPv4
> nat. If it helps just a little bit, that alone will make implementing IPv6
> worth it for smaller emerging operators. Buying IPv4 has become very
> expensive. Yes you can profit from selling a public IPv4 address to the
> customer, but there is also the risk that the customer just goes to the
> incumbent, which has old large pools of IPv4 and provides it for free.
> > >>
> > >> Regards,
> > >>
> > >> Baldur
> > >>
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> >
>

Re: IPv6 woes - RFC

[Baldur Norddahl]

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 which has the
highest impact on customers. Many NAT traversal techniques fail to work
with this type of NAT. STUN does not work with symmetric NAT.

You purposely want a lesser NAT type which makes NAT traversal easy. This
enables more applications to function despite the NAT. Almost every CPE
avoids symmetric NAT for one of the lesser types for this reason.


>
> unless some internal/original src is double using port/proto ... you
> should really
> have the ability to nat quite a large number of things to a single ipv4
> address.
>

There is no point in optimizing your customer per public CGN IP address
ratio and multiple reasons for not doing so. At some point you will
experience attacks on the CGN address or blacklisting in online games and
so on. Having less customers affected each time that happens is better.

In our network approximately 10% of new customers signed up within the last
year have asked to escape the CGN and get a public IP. This means I need
100 IPv4 addresses per 1000 new customers. Plus 4 IPv4 addresses for the
CGN server. What difference would it make if we could optimize those 4
addresses to be just 2 or maybe 1? What if it caused just a couple more
customers to request a public IP address because they got annoyed by a more
restrictive NAT or by failed sessions?

Regards,

Baldur

Re: IPv6 woes - RFC

[Brian Johnson]

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 gurus), not to mention some business applications 
that would break or be sub-optimal at best. I see CGN as the band aid to this 
issue, not the cure to the problem.

Discuss…?

 - Brian

> On Sep 23, 2021, at 10:46 AM, 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 certainly won’t do it.
> 
> I think the only way out is through. Unfortunately, the IPv6 resistant forces
> are making that hard for everyone else.
> 
> Owen
> 

Re: IPv6 woes - RFC

[Christopher Morrow]

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 address using a Mikrotik with
>> NAT.
>>
>
> It is our observation as the limit before you regularly run out of ports
> using Linux as a CGN server.
>
> It will still work if you have more users on an IP. The users will just
> experience session failures at peak. Low levels of that might show up as
> pictures that fail to load on a web page and be ok when the user reloads.
> This will increase the number of support calls and the number of customers
> that asks to escape the CGN. Or people will live with it and just think
> that the Internet connection is low quality.
>
>
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

unless some internal/original src is double using port/proto ... you should
really
have the ability to nat quite a large number of things to a single ipv4
address.

Of course as layers of nat get deeper you may lose some useful state :(
you may be able to use tcp seq numbers or other items in the state though
to overcome.

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 the only way out is through. Unfortunately, the IPv6 resistant forces
are making that hard for everyone else.

Owen

Re: IPv6 woes - RFC

[Colton Conor]

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 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
> > 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 16:48, Masataka Ohta 
> >>  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 on a CGN. If 
> >> you try to go further than that, for example by using symmetric NAT, you 
> >> will increase the number of customers that want to get a public IPv4 of 
> >> their own. That will actually decrease the combined efficiency and cause 
> >> you to need more, not less, IPv4 addresses.
> >>
> >> Without checking our numbers, I believe we have at least 10% of the 
> >> customers that are paying for a public IPv4 to escape our CGN. This means 
> >> a /24 will only be enough for about 2500 customers maximum. The "nat 
> >> escapers" drown out the efficiency of the NAT pool.
> >>
> >> The optimization you need to do is to make the CGN as customer friendly as 
> >> possible instead of trying to squeeze the maximum customers per CGN IPv4 
> >> address.
> >>
> >> Perhaps IPv6 can lower the number of people that need to escape IPv4 nat. 
> >> If it helps just a little bit, that alone will make implementing IPv6 
> >> worth it for smaller emerging operators. Buying IPv4 has become very 
> >> expensive. Yes you can profit from selling a public IPv4 address to the 
> >> customer, but there is also the risk that the customer just goes to the 
> >> incumbent, which has old large pools of IPv4 and provides it for free.
> >>
> >> Regards,
> >>
> >> Baldur
> >>
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>

Re: IPv6 woes - RFC

[Bjørn Mork]

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 imply that their prefix is split into the maximum
number of /48s. The number of routes is limited to the number of
separate network sites.  There is no need to worry about this number
ever exceeding the number of IPv4 prefixes.

And those /48s will most likely be filtered out of the global table
forever.  Enterprises wanting such a configuration will depend on
special transit agreements to carry and aggregate them for the rest of
the world.  This is not a problem.

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.





Bjørn

Re: IPv6 woes - RFC

[Baldur Norddahl]

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 limit before you regularly run out of ports
using Linux as a CGN server.

It will still work if you have more users on an IP. The users will just
experience session failures at peak. Low levels of that might show up as
pictures that fail to load on a web page and be ok when the user reloads.
This will increase the number of support calls and the number of customers
that asks to escape the CGN. Or people will live with it and just think
that the Internet connection is low quality.

Regards

Baldur

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 of ASes does not increase announcements in IPv4 nearly as
>> much as slow-start and repeated expanding requests for additional
>> IPv4 space have.
> 
> That *was* a factor, when increased number of subscribers
> meant more free addresses.

It’s still a factor as many providers are purchasing addresses rather than 
deploy CGN
because they don’t want the expensive phone calls CGN causes.

> Today, as /24 can afford hundreds of thousands of subscribers
> by NAT, only very large retail ISPs need more than one
> announcement for IPv4.

I fail to grasp this desire to move the majority of users from second class 
citizens of the
network to third class all in the interests of forestalling the inevitable.

> 
>>> As a result, size of global routing table will keep increasing
>>> unless there are other factors to limit it.
>> Sure, but it’s very clear that the rate of increase for IPv6 appears
>> to be roughly 1/8th that of IPv4,
> 
> It merely means IPv6 is not deployed at all by small ISPs
> and multihomed sites.

Not true. Judging by the number of /48s in the table, IPv6 is relatively
widely deployed by multi homed end sites and judging by the number
of /32 to /40 prefixes, also widely deployed by small-iso ISPs.

> 
> > The reality is that IPv4 will never be completely disaggregated into
> > /24s
> 
> You are so optimistic.

Yes, I’ll be surprised if (e.g. Apple, HP) part out their /8s in to /24s.

I’ll be surprised if a bunch of large organizations fully part out
their /16s and such.

I doubt any major eyeball ISPs will be significantly disbursing or
disaggregating any of their large blocks any time soon.

I suppose you can call that optimism. I call it realism.

Frankly, the faster IPv4 fully fragments, the better because that only
serves to make continuing to carry it all the more expensive, further
making the case for IPv6.

> 
> > and IPv6 will never be completely disaggregated into /48s, so
> > this is actually meaningless and not predictive in any way.
> 
> That IPv6 will be disaggregated into /40 or even /32 is disastrous.

Which it won’t.

It’s unlikely we will fully deploy 2000::/3 in the lifetime of anyone
on this list today.

>> There is no need for such motivation in IPv6 and better yet,
> 
> Then, in a long run, IPv6 will be disaggregated into /32 or /40.

Not likely… Too many providers and large organizations getting
/20s and /24s for that to happen.

>> since
>> the two organizations have fully globally unique addresses deployed
>> throughout their network, there's no risk of collisions in RFC-1918
>> space necessitating large renumbering projects to merge the networks.
> 
> You fully misunderstand why NAT is so popular today defeating IPv6.

Maybe… I certainly don’t understand why it is popular. It’s simply awful.

> Even if two organizations are merged, sites of the organizations
> are, in general, not merged.

Seems rather pointless and counterproductive.

> As private address space behind NAT is used by each site
> independently, there is no renumbering occur for the private
> addresses.

Well, as GUA would be globally unique to each site, there would be
a full ability to merge the sites _AND_ no renumbering cost.

Can you explain any way in which NAT is somehow better?

Owen

Re: IPv6 woes - RFC

[Mark Andrews]

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
> 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 16:48, Masataka Ohta 
>>  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 on a CGN. If 
>> you try to go further than that, for example by using symmetric NAT, you 
>> will increase the number of customers that want to get a public IPv4 of 
>> their own. That will actually decrease the combined efficiency and cause you 
>> to need more, not less, IPv4 addresses.
>> 
>> Without checking our numbers, I believe we have at least 10% of the 
>> customers that are paying for a public IPv4 to escape our CGN. This means a 
>> /24 will only be enough for about 2500 customers maximum. The "nat escapers" 
>> drown out the efficiency of the NAT pool.
>> 
>> The optimization you need to do is to make the CGN as customer friendly as 
>> possible instead of trying to squeeze the maximum customers per CGN IPv4 
>> address.
>> 
>> Perhaps IPv6 can lower the number of people that need to escape IPv4 nat. If 
>> it helps just a little bit, that alone will make implementing IPv6 worth it 
>> for smaller emerging operators. Buying IPv4 has become very expensive. Yes 
>> you can profit from selling a public IPv4 address to the customer, but there 
>> is also the risk that the customer just goes to the incumbent, which has old 
>> large pools of IPv4 and provides it for free.
>> 
>> Regards,
>> 
>> Baldur
>> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: IPv6 woes - RFC

[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.

On Wed, Sep 22, 2021 at 2:49 PM Baldur Norddahl
 wrote:
>
>
>
> On Wed, 22 Sept 2021 at 16:48, Masataka Ohta 
>  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 on a CGN. If you 
> try to go further than that, for example by using symmetric NAT, you will 
> increase the number of customers that want to get a public IPv4 of their own. 
> That will actually decrease the combined efficiency and cause you to need 
> more, not less, IPv4 addresses.
>
> Without checking our numbers, I believe we have at least 10% of the customers 
> that are paying for a public IPv4 to escape our CGN. This means a /24 will 
> only be enough for about 2500 customers maximum. The "nat escapers" drown out 
> the efficiency of the NAT pool.
>
> The optimization you need to do is to make the CGN as customer friendly as 
> possible instead of trying to squeeze the maximum customers per CGN IPv4 
> address.
>
> Perhaps IPv6 can lower the number of people that need to escape IPv4 nat. If 
> it helps just a little bit, that alone will make implementing IPv6 worth it 
> for smaller emerging operators. Buying IPv4 has become very expensive. Yes 
> you can profit from selling a public IPv4 address to the customer, but there 
> is also the risk that the customer just goes to the incumbent, which has old 
> large pools of IPv4 and provides it for free.
>
> Regards,
>
> Baldur
>

Re: IPv6 woes - RFC

[Baldur Norddahl]

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 on a CGN. If
you try to go further than that, for example by using symmetric NAT, you
will increase the number of customers that want to get a public IPv4 of
their own. That will actually decrease the combined efficiency and cause
you to need more, not less, IPv4 addresses.

Without checking our numbers, I believe we have at least 10% of the
customers that are paying for a public IPv4 to escape our CGN. This means a
/24 will only be enough for about 2500 customers maximum. The "nat
escapers" drown out the efficiency of the NAT pool.

The optimization you need to do is to make the CGN as customer friendly as
possible instead of trying to squeeze the maximum customers per CGN IPv4
address.

Perhaps IPv6 can lower the number of people that need to escape IPv4 nat.
If it helps just a little bit, that alone will make implementing IPv6 worth
it for smaller emerging operators. Buying IPv4 has become very expensive.
Yes you can profit from selling a public IPv4 address to the customer, but
there is also the risk that the customer just goes to the incumbent, which
has old large pools of IPv4 and provides it for free.

Regards,

Baldur

Re: IPv6 woes - RFC

[Denys Fedoryshchenko]

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 and routers.


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 IPv6.


Mark Andrews wrote:


There is nothing at the protocol level stopping AT offering a
similar level of service.


Setting up reverse DNS lookup for 16B address is annoying,
which may stop AT offering it.


Don’t equate poor implementation with the protocol being broken.


IPv6 is broken in several ways. One of the worst thing is its
address length.

Masataka Ohta

+1
Different scope problem: on inexpensive software BRAS solutions 
(PPPoE/IPoE). Enabling ipv6 just jacked up neighbour table usage and 
lookups cost in benchmark profiling, because now it have to keep for all 
users IPv6 /64 + MAC entries.
Another drop is neighbor discovery on device with 10k IPOE termination 
vlans and privacy extensions.
Also, i wonder how this changed? 
https://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/
Another problem is privacy extension and IoT, they are not supported in 
lwip stack shipped with most of IoT SoC. As far as i see in git it is 
not added yet too.
And SLAAC vs DHCPv6, again, first lacking some critical features, and 
second is often not implemented properly.


As many say - this is tiny, a drops of mess and complexities, but the 
ocean is made up of tiny drops. All these little things lead to the fact 
that very few want to mess with v6.

Re: IPv6 woes - RFC

[Masataka Ohta]

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 and repeated expanding requests for additional
IPv4 space have.


That *was* a factor, when increased number of subscribers
meant more free addresses.

Today, as /24 can afford hundreds of thousands of subscribers
by NAT, only very large retail ISPs need more than one
announcement for IPv4.


As a result, size of global routing table will keep increasing
unless there are other factors to limit it.


Sure, but it’s very clear that the rate of increase for IPv6 appears
to be roughly 1/8th that of IPv4,


It merely means IPv6 is not deployed at all by small ISPs
and multihomed sites.

> The reality is that IPv4 will never be completely disaggregated into
> /24s

You are so optimistic.

> and IPv6 will never be completely disaggregated into /48s, so
> this is actually meaningless and not predictive in any way.

That IPv6 will be disaggregated into /40 or even /32 is disastrous.


There is no need for such motivation in IPv6 and better yet,


Then, in a long run, IPv6 will be disaggregated into /32 or /40.


since
the two organizations have fully globally unique addresses deployed
throughout their network, there's no risk of collisions in RFC-1918
space necessitating large renumbering projects to merge the networks.


You fully misunderstand why NAT is so popular today defeating IPv6.

Even if two organizations are merged, sites of the organizations
are, in general, not merged.

As private address space behind NAT is used by each site
independently, there is no renumbering occur for the private
addresses.

Masataka Ohta

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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
>> IPv4 can but IPv6 can't be deployed at full scale,
> 
> Just this week We had our first customer asking if we can setup BGP to route 
> the /48 they received from the headquarters in the states.
> They are asking us to provide a few v4 addresses , but to use their own v6 
> block.
> Yes they are a large conglomerate with their own AS and a large v6 
> allocation, so not a common customer, but they have hundreds of offices 
> everywhere in the world where they are doing this... 
> I can just see the Cxx presenting their solution at some event and it 
> becoming the new thing to do
> What you are still using your providers addresses? You must be crazy... We 
> assign our own it's much better...
> A couple hundred corporations like this and the v6 table would surpass v4...

In such a case, I’m not convinced that’s a bad thing.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 that of IPv4, which means most small ISPs and
>>> multihomed sites do not support IPv6.
>> Well, it’s a combination. Even with full v6 adoption, the routing
>> table in v6 should be substantially smaller.
> 
> Not at all.
> 
>> Compare AS6939 v4 vs. v6:
> 
> That is not a meaningful comparison.
> 
> 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
and repeated expanding requests for additional IPv4 space have.

> As a result, size of global routing table will keep
> increasing unless there are other factors to limit it.

Sure, but it’s very clear that the rate of increase for IPv6 appears to be 
roughly 1/8th that of
IPv4, so even if IPv6 was 4x as expensive, the growth rate in cost would still 
be 1/2 that of
IPv4.

> An important factor is that, for IPv4 with globally
> routable /24, the absolute upper limit is merely 16M,
> to be looked up by a single memory access of conventional
> SRAM without needing TCAM. OTOH, IPv6 is hopeless.

The reality is that IPv4 will never be completely disaggregated into /24s and 
IPv6 will never
be completely disaggregated into /48s, so this is actually meaningless and not 
predictive
in any way.

> Another favorite factor for IPv4 is that, though most of
> routing table entries are generated from small entities
> having a /24 assuming NAT, if such entities are merged,
> renumbering is not so much a pain and they are motivated
> to rely on a single /24 and sell others. OTOH, there is
> no such motivation for IPv6.

There is no need for such motivation in IPv6 and better yet, since the two 
organizations
have fully globally unique addresses deployed throughout their network, there’s 
no risk
of collisions in RFC-1918 space necessitating large renumbering projects to 
merge the
networks. Indeed, all you need to do is turn on forwarding between the two 
networks
and you’re basically done.

As such, no, that’s an advantage that clearly goes to IPv6, not IPv4.

> 
>> 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,

Why would IPv6 become fragmented? When a provider the size of HE can
easily get a /24 from ARIN, what need is there for fragmentation. Sure, they
started with a /32 and they’re keeping that, but the equivalent growth in IPv4
would have resulted in a /20 + /19 + /18 + /17 + /16 + /15 + /14 + /13 and 
likely
an additional /12 eventually. So you get 7-8 prefixes for the same factor of 
growth
as 2 prefixes in IPv4.

It simply doesn’t make sense to claim that fragmentation in v6 will be nearly 
as bad
as it is in v4 because we don’t have the problems of slow start and we’re no 
longer
trying to balance scarcity against aggregation.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 > > wrote:
>> It appears that Owen DeLong via NANOG > > said:
>> 
>> 
>> Glad you noted this.  Thinking this was/is purely a hardware cycle problem 
>> related to normal/forced upgrade strategies.  On that point, most hardware I 
>> know of from 2004 in larger networks is long fully depreciated and sweating 
>> assets 15+ years can happen, but I don't personally think this is the 
>> biggest issue.
> 
> It’s certainly not purely hardware, but it also doesn’t require solving the 
> entire problem across the entire backend.
> 
> What is urgently needed is to fix the customer-facing front end so that it 
> speaks both protocols (or at least speaks IPv6).
> 
> This is a great question.  So when we approached this (going back a while 
> now) this is what I thought too.  But I was responsible to solve this end to 
> end.  So just updating front end (CPEs, network routers, DHCP, provisioning, 
> IP address planning, security, peering/transit, staff training, test 
> harnesses/plans, etc) was not sufficient to turn on IPv6. 
> 
> The high cost and time challenge issues were not upgrading backend servers to 
> IPv6, but backend provisioning systems, tools, customer support tools, their 
> training, and related items.  These systems were far more complex and costly 
> to address (especially when considering opportunity cost).   Without all of 
> this in place, we could not actually deploy IPv6 for production use (it’s not 
> just Turing it on, its our ability to operate it down to the person answer 
> the phone, the technician that installs and/or fixes/replaces items in home). 

This sounds like an eyeball environment… Note that my question was in the 
context of the laggard content providers.

Eyeball providers are going to have to do something eventually whether they 
like it or not and I’m a whole lot less worried about a forcing function for 
them.

The major eyeball providers have basically completed this. Hopefully that means 
that the vendors you’re using have been forced to upgrade their code and such 
to accommodate by now.

> Also at that time vendor CPE hardware was not as far along on IPv6 readiness 
> (approx mid-decade 2000s).  Getting reliable code at that time was hard with 
> a lot of brokenness (which also could not go into production until it was 
> reliable).  Perhaps this a non-issue today, but it certainly was not a 
> something that was “ready to go” even 10-15 years.   This (IPv6 readiness in 
> CPE code) was also competing with other priorities often blowing up timelines 
> which meant it had to wait as not releasing code into production on a strict 
> timeline was not an option for business reasons.

Sure, but a lot of that has gotten better in the recent years, largely driven 
by some of the major eyeball ISPs.

> All said and done, we got it completed, but it far most costly than we first 
> thought, and IPv4 costs did not go away after we were completed.  Sure it’s 
> possible to reduce those costs with an aggressive program, but it is not as 
> simple as many think.

Agreed… IPv4 costs for you, as an eyeball provider, can’t really go away until 
you can start doing one or more of the following:
1.  Raising your overall rates and providing a discount to 
IPv6-only customers
2.  Adding a surcharge to your billing for customers still 
requiring IPv4 services
3.  Turning off or reducing availability of IPv4 native services 
and moving more towards IPv4AAS
4.  Turning off IPv4 services outright

All of those basically depend on moving a few key laggard content providers 
forward.

>> 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.  I recall looking back 
>> when leading IPv6 turn-up, those were the biger problems to solve for.  
>> Often such systems are extremely expensive to touch and working on them 
>> required prioritization against direct revenue generating projects 
>> (opportunity cost) .  Replacing routers was just a money problem.
> 
> Why do those systems have to be updated in order to deliver the service to 
> the customer in both protocols?
> 
> Addressed in above comment.  

Eyeball… Now think about it in the context of a content provider… Especially 
one that is behind a CDN where it’s literally simply flipping the switch on the 
CDN
that says front end our stuff with both protocols.

> When it comes to turning on IPv6 and reducing your dependency on IPv4, your 
> mileage may vary (in terms of real costs, complexities and deployment).   

RE: IPv6 woes - RFC

[Brian Turnbow via NANOG]

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 first customer asking if we can setup BGP to route 
the /48 they received from the headquarters in the states.
They are asking us to provide a few v4 addresses , but to use their own v6 
block.
Yes they are a large conglomerate with their own AS and a large v6 allocation, 
so not a common customer, but they have hundreds of offices everywhere in the 
world where they are doing this... 
I can just see the Cxx presenting their solution at some event and it becoming 
the new thing to do
What you are still using your providers addresses? You must be crazy... We 
assign our own it's much better...
A couple hundred corporations like this and the v6 table would surpass v4...

Brian

Re: IPv6 woes - RFC

[Masataka Ohta]

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 IPv6.


Well, it’s a combination. Even with full v6 adoption, the routing
table in v6 should be substantially smaller.


Not at all.


Compare AS6939 v4 vs. v6:


That is not a meaningful comparison.

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.

As a result, size of global routing table will keep
increasing unless there are other factors to limit it.

An important factor is that, for IPv4 with globally
routable /24, the absolute upper limit is merely 16M,
to be looked up by a single memory access of conventional
SRAM without needing TCAM. OTOH, IPv6 is hopeless.

Another favorite factor for IPv4 is that, though most of
routing table entries are generated from small entities
having a /24 assuming NAT, if such entities are merged,
renumbering is not so much a pain and they are motivated
to rely on a single /24 and sell others. OTOH, there is
no such motivation for IPv6.


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,

Masataka Ohta

Re: IPv6 woes - RFC

[John Levine]

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 on request, and delegate the rDNS wherever you want.  One points at my 
server which
is in a rack somewhere, one points at the router on my home fiber connection.

Since I set it up they filter port 25 by default for obvious reasons but will 
unblock
if you ask nicely and sound like you know what you're doing.  Geolocation 
doesn't work,
and now and then someone (Wikipedia) decides it's an evil VPN and blocks or 
filters it
but I haven't found that to be much of a problem in practice.

R's,
John

Re: IPv6 woes - RFC

[Victor Kuarsingh]

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 problem
> related to normal/forced upgrade strategies.  On that point, most hardware
> I know of from 2004 in larger networks is long fully depreciated and
> sweating assets 15+ years can happen, but I don't personally think this is
> the biggest issue.
>
>
> It’s certainly not purely hardware, but it also doesn’t require solving
> the entire problem across the entire backend.
>
> What is urgently needed is to fix the customer-facing front end so that it
> speaks both protocols (or at least speaks IPv6).
>

This is a great question.  So when we approached this (going back a while
now) this is what I thought too.  But I was responsible to solve this end
to end.  So just updating front end (CPEs, network routers, DHCP,
provisioning, IP address planning, security, peering/transit, staff
training, test harnesses/plans, etc) was not sufficient to turn on IPv6.

The high cost and time challenge issues were not upgrading backend servers
to IPv6, but backend provisioning systems, tools, customer support tools,
their training, and related items.  These systems were far more complex and
costly to address (especially when considering opportunity cost).   Without
all of this in place, we could not actually deploy IPv6 for production use
(it’s not just Turing it on, its our ability to operate it down to the
person answer the phone, the technician that installs and/or fixes/replaces
items in home).

Also at that time vendor CPE hardware was not as far along on IPv6
readiness (approx mid-decade 2000s).  Getting reliable code at that time
was hard with a lot of brokenness (which also could not go into production
until it was reliable).  Perhaps this a non-issue today, but it certainly
was not a something that was “ready to go” even 10-15 years.   This (IPv6
readiness in CPE code) was also competing with other priorities often
blowing up timelines which meant it had to wait as not releasing code into
production on a strict timeline was not an option for business reasons.

All said and done, we got it completed, but it far most costly than we
first thought, and IPv4 costs did not go away after we were completed.
Sure it’s possible to reduce those costs with an aggressive program, but it
is not as simple as many think.


> 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.  I recall looking
> back when leading IPv6 turn-up, those were the biger problems to solve
> for.  Often such systems are extremely expensive to touch and working on
> them required prioritization against direct revenue generating projects
> (opportunity cost) .  Replacing routers was just a money problem.
>
>
> Why do those systems have to be updated in order to deliver the service to
> the customer in both protocols?
>

Addressed in above comment.

When it comes to turning on IPv6 and reducing your dependency on IPv4, your
mileage may vary (in terms of real costs, complexities and deployment).

Regards,

Victor K


> I mean sure, you’ll probably need to fix some logging databases that think
> that a customers address can be logged as a uint32_t, but that’s a
> relatively small number of systems that need to be updated in that case and
> it’s not like expanding the field to uint128_t in the database is
> incompatible with the old software during the upgrade process.
>
> I am by far not saying I agree with choices made by hold-outs, but I also
> understand this is for many, not just an engineering problem to solve.
>
>
> I agree there are some systems that may make this more complex in some
> environments, but I don’t agree that it’s
> impossible (or even particularly difficult) for a content provider to
> deliver their content on both protocols today even
> if they don’t upgrade their back-end systems.
>
> Owen
>
>

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 IPv4 was the optional protocol.
> That's a fantasy world.  Time to get out of la-la land now.

No, I’m counting them as if they are the increasing cost of continuing to 
support IPv4.

> Your edge routers can do CGN for all connected users just fine. Yes,
> there is still a cost both in resources and management, but you'll have
> to weigh that against the cost of doing dual-stack on the same box.  I'm
> not convinced dual-stack wins.

It does. At least in my environments.

> Don't know what you're thinking of wrt support calls, but dual-stack has
> some failure modes which are difficult to understand for both end users
> and support.  NAT is pretty well understood in comparison.

Single layer NAT, sure. But double-layer NAT has some oddities that you
might not have encountered yet…

1.  Products which are built on really strange assumptions about everyone
having the same NAT environment.

For example, Philips Hue makes an assumption that if you are in the
same household, your Hue Gateway and your phones and laptops will
all have the same public IP address.

This has two unexpected ramifications:

1.  You cannot actually complete their registration process for 
their
cloud services if you don’t NAT everything to the same address
or proxy it all through a common proxy address.

2.  If you are behind CGN, you and your neighbors are going to be
considered a single household (at least everyone behind the
same CGN address). Of course, this assumes that you get a
consistent single public CGN address for everything in your
house. If you don’t, then you get a combination of this problem
with problem 1 above and life gets very interesting.

2.  NAT Traversal technologies that don’t cope well with an added layer.

3.  Added and inconsistent latency through CGN boxes degrading
several online experiences, including voice, interactive video,
and most of all several types of gaming.

There are many more and each of them generates additional support calls
to the ISP about “The internet is broken”.

> Your routing tables won't grow with IPv4 or CGN.  They grow when you add
> IPv6.

Um, please review the IPv4 routing table report over the past few years
and tell me that again.

For your convenience: 
https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp%2dactive%2etxt=Active%20BGP%20entries%20%28FIB%29=Active%20BGP%20entries%20%28FIB%29=step


> 
>> Increased cost of developers having to work around NAT and NAT
>> becoming ever more complex with multiple layers, etc.
> 
> And this can be avoided by reconfiguring the local network somehow?  Or
> are we talking about an Internet without IPv4?  This is even more
> fantastic than the idea that IPv4 is optional in the local network.

We are talking about internet where IPv4 prevalence continues to drop. Whether
it can be avoided or not, however, it is a factor in the ever increasing cost 
of IPv4.

> 
>> All of these are the things driving the ever increasing cost of IPv4
>> services, not just the cost of the addresses.
> 
> Yes, the cost of addresses is not prohibitive, and there is no
> indication it will be.

Agreed… But the other costs are also continuing to increase. None of these
costs exist in IPv6 save a one-time deployment cost.

> The consolidation of hosting services have reduced the need for globally
> routable addresses.  You don't host your own mail server and web server
> anymore, even if you're a large organisation.

Lots do, actually.

>  Most ISPs haven't yet
> taken advantage of this.  They are still giving globally routable IPv4
> addresses to customers which have no need for that.  These addresses can
> be re-allocated for CGN if there is a need. This is obviously still not
> free, but it does limit the price of fresh IPv4 addresses.

Lots of things you don’t expect break when you stop giving at least one IPv4 GUA
to your customers.

> The other costs you list will not affect an IPv4 only shop at all.

This simply isn’t true.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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
>>> Akamai.
>> I wasn't talking about switches and routers.
> 
> 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 IPv6.

Well, it’s a combination. Even with full v6 adoption, the routing table in v6 
should be substantially smaller.

Compare AS6939 v4 vs. v6:

+   6939 is probably the most v6 fully implemented ASN on the planet.
+   6939 announces 4 of their own prefixes in v6 (They do originate 19 
prefixes on behalf of customers)
+   6939 announces at least 41 of their own prefixes in v4 and originates 
myriad customer prefixes in v4.

That’s more than 10x the prefixes in v4 for the same network fully dual-stacked 
vs. what is announced in v6.

v4 is so thoroughly fragmented and v6 is a lot less likely to become so.

> 
> 
> Mark Andrews wrote:
> 
> > There is nothing at the protocol level stopping AT offering a
> > similar level of service.
> 
> Setting up reverse DNS lookup for 16B address is annoying,
> which may stop AT offering it.

Why would one need to do that? For customers with a static prefix that want 
reverse DNS capabilities,
offer to point the NS records for their prefix wherever they want and let them 
run their own DNS servers.

> 
> > Don’t equate poor implementation with the protocol being broken.
> 
> IPv6 is broken in several ways. One of the worst thing is its
> address length.

Why do you think 128 bits isn’t enough?

Owen

Re: IPv6 woes - RFC

[Masataka Ohta]

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 technical points, it could
have won.

Masataka Ohta

Re: IPv6 woes - RFC

[Stephen Satchell]

On 9/18/21 11:20 PM, Masataka Ohta wrote:

Mark Andrews wrote:

 > There is nothing at the protocol level stopping AT offering a
 > similar level of service.

Setting up reverse DNS lookup for 16B address is annoying,
which may stop AT offering it.


How many mail servers are on the Internet today?  I don't know.  How  
many business customers (large and small) does AT have?  I don't know,  
and don't expect ever to know.  I assume by "16B" you mean "16 billion";  
if so, why did you select that value?


Based on the routing tables on my edge router for my existing  
connection-based allocation, I have a IPv6 address block with a /60  
prefix.  The AT SBCIS allocation for IPv6 is 2600:1700::/28  
(4.294.967.296 /60 prefixes), and the parent range is /12.  (In a prior  
message, someone mentioned that their customer was able to obtain a  
static /56 IPv6 address block.  Don't know how they did that, unless  
they are tunneling to a different provider like HE.)


AT does offer PTR records for IPv4 static addresses -- I have a set of  
static IPv4 addresses (which I pay for monthly) and one associated  
IN-ADDR.ARPA PTR record.  (I used to have *two* sets of static IP IPv4  
addresses -- both paid for monthly -- and two associated IN-ADDR.ARPA  
PTR records, but I released one of those sets when I discontinued my  
long-time DSL service with AT)


From the AT community forum, from two years ago, a moderator says  
this:  "IPv6 Its [sic] are assigned to your connection; IPv4 static IP  
blocks are assigned to you. This is why they still don't offer reverse  
PTR delegation."


What's missing?  A static prefix of IPv6, and one IP6.ARPA PTR record.  
I'm willing to pay for IPv6 static addresses, as long as I can get the  
one IP6.ARPA PTR record for my mail server.  Connection-based prefix  
would be fine, but I still need the PTR record to satisfy the Best  
Practices requirements for mail servers.


(Why do I run my own mail server?  When I started out with DSL many  
years ago, I used Pacific Bell's mail servers.  The IP reputation was to  
the point that mail from my systems was blocked by so many mail servers  
around the 'Net.  So, Postfix locally.  Never looked back.)

Re: IPv6 woes - RFC

[Saku Ytti]

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 being affected by availability
heuristics bias, you think that the things you understand must contain
the solution to the problem.

IPv6 problem is, very few companies in developed markets need it to do
business, as customers are just bouncing between established players,
no new organic growth. Those companies choosing to do it increase
their cost for no utility, so it is an objectively bad decision for
many to do IPv6.
People who have sentimental attachment to versions of IP protocols are
a minority, most just want that customers continue paying their
invoices and keep accepting the product.

It is almost guaranteed we are married to IPv4 past our life cycles,
because there will be a lot of drivers to keep it. Even though
dual-stack increases cost for our vendors and us, each of us can
transfer the cost to our customers with margins, fixing it would mean
less revenue. Like infosec, it'll want things to remain relatively
broken, as everyone in position to change it are capitalising on
keeping it.



-- 
  ++ytti

Re: IPv6 woes - RFC

[Masataka Ohta]

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 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 IPv6.


Mark Andrews wrote:

> There is nothing at the protocol level stopping AT offering a
> similar level of service.

Setting up reverse DNS lookup for 16B address is annoying,
which may stop AT offering it.

> Don’t equate poor implementation with the protocol being broken.

IPv6 is broken in several ways. One of the worst thing is its
address length.

Masataka Ohta

Re: IPv6 woes - RFC

[Stephen Satchell]

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 business internet and they were able to get a static /56 (For some reason, 
AT refused to do a /48, but we did push them on it.)


When I checked, there were NO options for ANY static IPv6.  Perhaps the 
devil is in the details of my particular "business Internet" package. 
If "package" is the right term; I use them only for upstream 
connectivity and rental of IP (and IPv6) addresses.


If it turns out they won’t do PTR or more likely NS for our ip6.arpa zone, then we’ll probably start looking for an alternative provider 


That's the problem with a facilities-based ISP, there are no alternative 
providers.  Oh, sure, I could get Spectrum here.  Indeed, I had a 
circuit: when I had their business service I had even more problems with 
them than I do with this one.



or get an HE /48 over a tunnel which will do PTR or NS records appropriately.


Hurricane Electric?  Seriously?  I had them when I was working at a web 
host company quite a while ago.  Have they improved their service desk? 
The downside is that I would have a serial pair of points of failure for 
my connectivity.


IPv6 was supposed to SOLVE the problems, not create more problems.

I look back longingly to that product from the 80s:  Internet-in-a-box.

I also remember the birth of Interop, when I visited Telebit at a 
session to work out the interoperability snags in PPP implementations 
among a handful of vendors.

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

I haven’t tried the PTR thing yet, but I do have a small business client that 
has AT business internet and they were able to get a static /56 (For some 
reason, AT 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 
we’ll probably start looking for an alternative provider or get an HE /48 over 
a tunnel which will do PTR or NS records appropriately.

Owen


> On Sep 18, 2021, at 14:19 , Stephen Satchell  wrote:
> 
> 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
> 
> 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, and 
> to protect the LAN devices from outside interference by rules in the NFTABLES 
> firewall that include connection tracking on outbound requests.  (IPv4 will 
> still use NAT to keep nefarious people from probing my internals.)
> 
> Specifically, when I was doing my mail server refresh (moving from Red Hat to 
> Canonical) I decided it was time to offer IPv6 connectivity in the mail 
> server to "future proof" my setup.  That included adding  records in my 
> DNS zone files.  Failure!  The issues:
> 
> 1.  I learned that there are no "static addresses" in IPv6, as far as AT 
> was concerned.  By all appearances, though, the IPv6 /64 is relatively 
> static, for now, similar to the way that early cable modem deployments kept 
> the same IPv4 addresses.  (Until the cable people started forcing changes on 
> DHCP lease renewal, that is.)
> 
> 2.  My request for PTR records was denied, which means I can't satisfy Best 
> Practices for a mail server in the IPv6 space.  No PTR records, no 
> redirection of ip6.apra space, nothing.  I include AT's refusal below.
> 
> 3.  I don't know how to get an IPv6 allocation from ARIN, how to request AT 
> to route it, or how to deal with the DNS server issues.  Oh, I know how to 
> configure BIND9; I would prefer using a 24/7/365 provider.  For example, my 
> master zone files are with Register.com, so if my circuit goes down the name 
> resolution still happens.  Register.com appears not to provide reverse-DNS 
> PTR zone support (in6.arpa).  A Google search turned up NOTHING for in6.arpa 
> hosting.
> 
> That tells me that IPv6 is not "Internet Ready" for small users.  Given the 
> level of FU responses I get trying to work with it, I will stop banging my 
> head against the wall.
> 
> So I stick with IPv4, because that will be the "standard" until the day I 
> die, as far as I can tell.
> 
> (I removed the  record, so as not to confuse mail server that DO operate 
> IPv6.)
> 
>> Subject: RE: Need IPv6 PTR record for my IPv6 mail server
>> Date: Mon, 19 Jul 2021 12:52:53 +
>> From: Prov-DNS 
>> To: Prov-DNS , a...@satchell.net 
>> Hello We don't process DNS request on IPv6 addresses. We only process DNS
>> request on IPv4 static assigned addresses.  If you would like us to
>> process a DNS request for you on a IPv4 address please provide the
>> following information.
>> IPv4 address you would like the record created for Host name you would > 
>> like that IP address pointed to 
> >
>> Thanks
>> Michael AT Prov-DNS
>> -Original Message-
>> From: Stephen Satchell 
>> Sent: Friday, July 16, 2021 5:42 PM
>> To: DNSUpdates cB 
>> Subject: Need IPv6 PTR record for my IPv6 mail server
>> Here is the record I need inserted into your ip6.arpa DNS zone:
> 2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. 0 
> IN PTR smtp.satchell.net.
>> This is the result from the question section of a dig(1) request for the PTR 
>> record for my IPv6 address 2600:1700:79b0:ddc0::32, and the fully-qualified 
>> domain name of the server.
>> You can verify the information using dig smtp.satchell.net  and checking 
>> the reverse.
>> This is the only server in my collection that needs the IPv6 pointer.

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 my office, I have a Cisco SPA112 two-port ATA.  It's been 
> discontinued but Cisco says they will support it through 2025 and they 
> shipped a firmware update in 2019.  It works fine on IPv4 behind a NAT. It 
> has no v6 support at all and never will.  Multiply that by a zillion and you 
> can see that IPv4 isn't going away any time soon.

This isn’t about removing IPv4 from every last corner of the internet. It’s 
about adding IPv6 to the content providers that are blocking the ability to 
build new eyeball networks v6 only.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 
> >> expect these companies all have plans
> >to support v6 eventually, someday, once they're retired and replaced all of 
> >the old junk that handles v6 poorly or
> >not at all, but you know about accountants and depreciation.
> >
> >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.  I was talking about every 
> single piece of software and equipment that
> they use for support and marketing and customer service and all the other 
> stuff that big companies do.
> 
> As I may have said once or twice, eventuallly it'll all be replaced so it 
> works on IPv6 but we're not holding our breath.
> 
> Glad you noted this.  Thinking this was/is purely a hardware cycle problem 
> related to normal/forced upgrade strategies.  On that point, most hardware I 
> know of from 2004 in larger networks is long fully depreciated and sweating 
> assets 15+ years can happen, but I don't personally think this is the biggest 
> issue.

It’s certainly not purely hardware, but it also doesn’t require solving the 
entire problem across the entire backend.

What is urgently needed is to fix the customer-facing front end so that it 
speaks both protocols (or at least speaks IPv6).

> 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.  I recall looking back 
> when leading IPv6 turn-up, those were the biger problems to solve for.  Often 
> such systems are extremely expensive to touch and working on them required 
> prioritization against direct revenue generating projects (opportunity cost) 
> .  Replacing routers was just a money problem.

Why do those systems have to be updated in order to deliver the service to the 
customer in both protocols?

I mean sure, you’ll probably need to fix some logging databases that think that 
a customers address can be logged as a uint32_t, but that’s a relatively small 
number of systems that need to be updated in that case and it’s not like 
expanding the field to uint128_t in the database is incompatible with the old 
software during the upgrade process.

> I am by far not saying I agree with choices made by hold-outs, but I also 
> understand this is for many, not just an engineering problem to solve. 

I agree there are some systems that may make this more complex in some 
environments, but I don’t agree that it’s
impossible (or even particularly difficult) for a content provider to deliver 
their content on both protocols today even
if they don’t upgrade their back-end systems.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> 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 of 
>> the old junk that handles v6 poorly or
>> not at all, but you know about accountants and depreciation.
>> 
>> 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.  I was talking about every 
> single piece of software and equipment that
> they use for support and marketing and customer service and all the other 
> stuff that big companies do.

That doesn’t all have to change in order to make their services available on 
IPv6 also.

IPv6 is not an all-or-nothing thing.

If your backend is all IPv4 all the time and you want to keep it that way, more 
power to you. I encourage my competitors to try that.

However, if your customer-facing services are IPv4-only, that’s not hard to fix 
in most cases and it’s really obnoxious not to do so.

> As I may have said once or twice, eventuallly it'll all be replaced so it 
> works on IPv6 but we're not holding our breath.

I’m not holding my breath, but I’m also trying to argue reasonable approaches 
and realistic solutions here.

You seem to be looking for excuses to claim the problem that needs to be solved 
is harder than it is to justify not solving it.

Owen

Re: IPv6 woes - RFC

[John Levine]

According to Mark Andrews :
>It tells you that AT don’t treat IPv6 on equal footing to IPv4 and nothing 
>more.

Indeed but since AT 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,
John

PS: that's separate from what he said about equipment which nomninally has v6 
support but not
in a way that you can actually use.
-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: IPv6 woes - RFC

[Mark Andrews]

It tells you that AT don’t treat IPv6 on equal footing to IPv4 and nothing 
more.

There is nothing at the protocol level stopping AT 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 Satchell  wrote:
> 
> 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
> 
> 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, and 
> to protect the LAN devices from outside interference by rules in the NFTABLES 
> firewall that include connection tracking on outbound requests.  (IPv4 will 
> still use NAT to keep nefarious people from probing my internals.)
> 
> Specifically, when I was doing my mail server refresh (moving from Red Hat to 
> Canonical) I decided it was time to offer IPv6 connectivity in the mail 
> server to "future proof" my setup.  That included adding  records in my 
> DNS zone files.  Failure!  The issues:
> 
> 1.  I learned that there are no "static addresses" in IPv6, as far as AT 
> was concerned.  By all appearances, though, the IPv6 /64 is relatively 
> static, for now, similar to the way that early cable modem deployments kept 
> the same IPv4 addresses.  (Until the cable people started forcing changes on 
> DHCP lease renewal, that is.)
> 
> 2.  My request for PTR records was denied, which means I can't satisfy Best 
> Practices for a mail server in the IPv6 space.  No PTR records, no 
> redirection of ip6.apra space, nothing.  I include AT's refusal below.
> 
> 3.  I don't know how to get an IPv6 allocation from ARIN, how to request AT 
> to route it, or how to deal with the DNS server issues.  Oh, I know how to 
> configure BIND9; I would prefer using a 24/7/365 provider.  For example, my 
> master zone files are with Register.com, so if my circuit goes down the name 
> resolution still happens.  Register.com appears not to provide reverse-DNS 
> PTR zone support (in6.arpa).  A Google search turned up NOTHING for in6.arpa 
> hosting.
> 
> That tells me that IPv6 is not "Internet Ready" for small users.  Given the 
> level of FU responses I get trying to work with it, I will stop banging my 
> head against the wall.
> 
> So I stick with IPv4, because that will be the "standard" until the day I 
> die, as far as I can tell.
> 
> (I removed the  record, so as not to confuse mail server that DO operate 
> IPv6.)
> 
>> Subject: RE: Need IPv6 PTR record for my IPv6 mail server
>> Date: Mon, 19 Jul 2021 12:52:53 +
>> From: Prov-DNS 
>> To: Prov-DNS , a...@satchell.net 
>> Hello We don't process DNS request on IPv6 addresses. We only process DNS
>> request on IPv4 static assigned addresses.  If you would like us to
>> process a DNS request for you on a IPv4 address please provide the
>> following information.
>> IPv4 address you would like the record created for Host name you would > 
>> like that IP address pointed to 
> >
>> Thanks
>> Michael AT Prov-DNS
>> -Original Message-
>> From: Stephen Satchell 
>> Sent: Friday, July 16, 2021 5:42 PM
>> To: DNSUpdates cB 
>> Subject: Need IPv6 PTR record for my IPv6 mail server
>> Here is the record I need inserted into your ip6.arpa DNS zone:
> 2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. 0 
> IN PTR smtp.satchell.net.
>> This is the result from the question section of a dig(1) request for the PTR 
>> record for my IPv6 address 2600:1700:79b0:ddc0::32, and the fully-qualified 
>> domain name of the server.
>> You can verify the information using dig smtp.satchell.net  and checking 
>> the reverse.
>> This is the only server in my collection that needs the IPv6 pointer.
> 

Re: IPv6 woes - RFC

[Tim Howe]

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 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.  
> 
>   Owen, I have nothing but respect for you, but this is a
> fantasy...  I provide FTTx services to business and residential.  I had
> to fight, and grind, and test for over a year to get a mix of hardware
> and software that would provide anything resembling IPv6 equivalent
> services to most of our customers.  The only devices in my network that
> worked with few problems are my Adtran gpon/xgs-pon cards (try to find
> DHCPv6 option-18 support on anything else)... EVERYTHING else I used
> from my Juniper routers to customer CPE had to go through more rounds
> of testing and bug fixes than I could name - for years.
> 
>   I've provided static v6 services to business customers for a
> long time (with no takers), but dynamic, scalable residential services
> was very hard.  There are still holes in our infrastructure because most
> vendors I am dealing with are doing very little to no v6 testing and
> still think I am a weirdo for asking for it.  Every ACS vendor is
> either just now working on it, or thinks they have it until I point out
> to them that they don't.  There have been some vendors that were good
> to work with: Juniper fixed the bugs I reported once I was able to
> prove to them it really was on there end (DHCPv6 relay server).  ZyXel
> has been good to work with; they care about and fix bugs that are
> reported.
> 
>   There are also big vendors I won't work with any more because
> they do not have full v6 support for features I need, and they have no
> plans to have it.  I'm not a big enough customer for them to care about
> what I want.  I have devices with 2 year old software and zero v6
> support and none is coming ever; these are not no-name vendors; they
> are big.
> 
>   People who think modern equipment is ready to provide native
> dual-stack services at scale to their customers are either using stuff
> very similar to mine, or are simply not doing it yet or have a lot of
> compromises.
> 
> --TimH

Re: IPv6 woes - RFC

[Jared Mauch]

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 and we will get there. I'm expecting another decade or two though. 

Sent from my TI-99/4a

> On Sep 18, 2021, at 4:29 PM, John R. Levine  wrote:
> 
> IPv4 isn't going away any time soon.

Re: IPv6 woes - RFC

[Stephen Satchell]

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


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, and to protect the LAN devices from outside interference by 
rules in the NFTABLES firewall that include connection tracking on 
outbound requests.  (IPv4 will still use NAT to keep nefarious people 
from probing my internals.)


Specifically, when I was doing my mail server refresh (moving from Red 
Hat to Canonical) I decided it was time to offer IPv6 connectivity in 
the mail server to "future proof" my setup.  That included adding  
records in my DNS zone files.  Failure!  The issues:


1.  I learned that there are no "static addresses" in IPv6, as far as 
AT was concerned.  By all appearances, though, the IPv6 /64 is 
relatively static, for now, similar to the way that early cable modem 
deployments kept the same IPv4 addresses.  (Until the cable people 
started forcing changes on DHCP lease renewal, that is.)


2.  My request for PTR records was denied, which means I can't satisfy 
Best Practices for a mail server in the IPv6 space.  No PTR records, no 
redirection of ip6.apra space, nothing.  I include AT's refusal below.


3.  I don't know how to get an IPv6 allocation from ARIN, how to request 
AT to route it, or how to deal with the DNS server issues.  Oh, I know 
how to configure BIND9; I would prefer using a 24/7/365 provider.  For 
example, my master zone files are with Register.com, so if my circuit 
goes down the name resolution still happens.  Register.com appears not 
to provide reverse-DNS PTR zone support (in6.arpa).  A Google search 
turned up NOTHING for in6.arpa hosting.


That tells me that IPv6 is not "Internet Ready" for small users.  Given 
the level of FU responses I get trying to work with it, I will stop 
banging my head against the wall.


So I stick with IPv4, because that will be the "standard" until the day 
I die, as far as I can tell.


(I removed the  record, so as not to confuse mail server that DO 
operate IPv6.)



Subject: RE: Need IPv6 PTR record for my IPv6 mail server
Date: Mon, 19 Jul 2021 12:52:53 +
From: Prov-DNS 
To: Prov-DNS , a...@satchell.net 


Hello 
We don't process DNS request on IPv6 addresses. We only process DNS

request on IPv4 static assigned addresses.  If you would like us to
process a DNS request for you on a IPv4 address please provide the
following information.

IPv4 address you would like the record created for Host name you would > like that IP address pointed to 

>

Thanks
Michael AT Prov-DNS

-Original Message-
From: Stephen Satchell 
Sent: Friday, July 16, 2021 5:42 PM
To: DNSUpdates cB 
Subject: Need IPv6 PTR record for my IPv6 mail server

Here is the record I need inserted into your ip6.arpa DNS zone:



2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. 0 
IN PTR smtp.satchell.net.


This is the result from the question section of a dig(1) request for the PTR 
record for my IPv6 address 2600:1700:79b0:ddc0::32, and the fully-qualified 
domain name of the server.

You can verify the information using dig smtp.satchell.net  and 
checking the reverse.


This is the only server in my collection that needs the IPv6 pointer.

Re: IPv6 woes - RFC

[Tim Howe]

On Fri, 17 Sep 2021 21:15:00 -0700
Owen DeLong via NANOG  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.

Owen, I have nothing but respect for you, but this is a
fantasy...  I provide FTTx services to business and residential.  I had
to fight, and grind, and test for over a year to get a mix of hardware
and software that would provide anything resembling IPv6 equivalent
services to most of our customers.  The only devices in my network that
worked with few problems are my Adtran gpon/xgs-pon cards (try to find
DHCPv6 option-18 support on anything else)... EVERYTHING else I used
from my Juniper routers to customer CPE had to go through more rounds
of testing and bug fixes than I could name - for years.

I've provided static v6 services to business customers for a
long time (with no takers), but dynamic, scalable residential services
was very hard.  There are still holes in our infrastructure because most
vendors I am dealing with are doing very little to no v6 testing and
still think I am a weirdo for asking for it.  Every ACS vendor is
either just now working on it, or thinks they have it until I point out
to them that they don't.  There have been some vendors that were good
to work with: Juniper fixed the bugs I reported once I was able to
prove to them it really was on there end (DHCPv6 relay server).  ZyXel
has been good to work with; they care about and fix bugs that are
reported.

There are also big vendors I won't work with any more because
they do not have full v6 support for features I need, and they have no
plans to have it.  I'm not a big enough customer for them to care about
what I want.  I have devices with 2 year old software and zero v6
support and none is coming ever; these are not no-name vendors; they
are big.

People who think modern equipment is ready to provide native
dual-stack services at scale to their customers are either using stuff
very similar to mine, or are simply not doing it yet or have a lot of
compromises.

--TimH