Re: Comcast Customer Owned Modem Firmware : WAS : Xfi Advances Security (comcast)

[Jay Hennigan]

On 9/16/21 08:13, Tom Beecher wrote:

Does Comcast actually allow customers who own their own modems full 
management of the modem firmware? As far as I have been aware since my 
time at Adelphia 20-odd years ago, that has never been allowed by 
provider; all users of a given model had the same firmware enforced, 
customer owned or leased didn't matter.


I can't speak for Comcast, but my local cable company indeed flashes 
COAM modem firmware to whatever their latest approved version is at 
least on installation and perhaps periodically thereafter. When I bought 
my modem and it was first put online its firmware was upgraded 
over-the-wire as one of the first steps of provisioning.


Even owned modems are TTBOMK very limited on what the customer can do 
with them. SNMP typically isn't available on the ethernet side for 
example. About all one can do is parse the HTML on 192.168.100.1 (in 
most cases) to get an idea of signal quality, etc. If the modem has 
built-in wi-fi you can expect the cable company to enable it for their 
roaming customers to piggyback on your RF, resulting in interference 
even if you turn off your own wi-fi in the modem.


Leasing a modem from the cable company seems to universally be a 
terrible deal for the customer. DOCSIS 3.1 modems go for about $100 new 
retail in quantities of one. I'm sure they're much less when a cable 
company buys them by the tens of thousands in bulk packaging. At $10 to 
$16 per month it makes zero sense for anyone to rent one. Of course the 
phone companies did the same thing for decades with extension phones.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: Fastly Peering Contact?

[Job Snijders via NANOG]

Hi Bryan,

On Thu, 16 Sep 2021 at 19:53, Bryan Holloway  wrote:

> Hey all ... looking for a Fastly (54113) peering contact that might be
> able to get me in touch with the right folks to do stuff.


I’ll follow up with you off-list.

Kind regards,

Job

Fastly Peering Contact?

[Bryan Holloway]

Hey all ... looking for a Fastly (54113) peering contact that might be 
able to get me in touch with the right folks to do stuff.


E-mails to the 'policy' peeringdb contact don't seem to be getting through.

Thanks!

- bryan

Re: IPv6 woes - RFC

[Masataka Ohta]

John Curran wrote:


If by "design choices" you mean the tradeoffs accepted in selecting a
particular candidate protocol and declaring victory, then I’d
strongly disagree.


What actually happened is that SIP was chosen but modified
by IPng directorates to pretend, for political purposes, IPng
were a merger of all the proposals only to make the result
totally unusable, during which address length was extended
from 8B to 16B to accommodate so infamous XNS style auto
configuration.

Masataka Ohta

Webinar TODAY + VIDEO - Ep.1 "Internet Innovators" + more

[Nanog News]

*️  Webinar TODAYJoin us for a Fireside Chat w/ CENIC Nick Plunkett *

*Date + Time:* September 16, 11am - 1pm PST / 2pm - 4pm EST

*Agenda: *Join us for a fireside chat discussion. We will talk about
several topics including:

   - The path taken to a tech career
   - What is CENIC
   - Opportunities for volunteer or educational work

*Speaker: *Nick Plunkett, Network Interconnection Engineer - Internet
Services at CENIC

*REGISTER NOW  *



*VIDEO | Watch Ep.1 "Internet Innovators" w/ Vint Cerf*

*NANOG Discusses Past, Present, Future of Internet with a Internet Legend *

Have you checked out our new web series *ft. the brightest and boldest tech
minds* of our time? Welcome to NANOG’s* Internet Innovators*!

*Join us,* every month as we look to the past, present and future of the
Internet and talk to the innovators who were actually there.

*Don't have the time for a full episode? *Watch S1, Ep.1 CLIP -
A legendary “father” of Internet Vint Cerf
discusses “what it takes to be revolutionary.”

*STAY TUNED. *Join us Wednesday, Sept. 30 for Ep. 2 of *Internet
Innovators.* The candid, entertaining and never one to not address the
elephant in the room, Chief scientist of *Telstra Internet *Geoff Huston
will have an intimate conversation about why he thinks the Internet is
busted.

*WATCH Ep.1 NOW
*


*Now Accepting Applications for NANOG 83 Peering Coordination Forum *

*The Peering Coordination Forum* is a 90-minute session that will take
place Nov. 1 during the NANOG 83 conference. The forum is an opportunity
for attendees to meet + network with others in the peering community
present at NANOG.

*NANOG 83 Peering Coordination Forum *applications will remain open until
we have 20 applications. If you are a Peering Representative with a table,
you will have the opportunity to request a plexiglass shield for your table.

*APPLY NOW* 


* Hybrid NANOG 83 is Just Around the Corner *

Have you heard? NANOG is now a hybrid
 platform, providing
equally robust programming virtually and/or in-person. *Join us *from the
comfort of your laptop or see us in-person in Minneapolis, MN on Nov 1 - 3.
We can't wait to see you!

*REGISTER NOW  * 

Re: IPv6 woes - RFC

[Masataka Ohta]

Baldur Norddahl wrote:

>> But in fact with local number portability, you cannot rely
>>>  

>>> You are confusing number portability and call forwarding

> I am not confusing anything. Nobody said anything about number
> portability in the above quote.

But, Shane Ronan wrote:

> But in fact with local number portability, you cannot rely on the
> county code to tell you where to route a telephone call anymore.
> Which is many calls result in a data dip to provide you the routing
> information from a central repository.

OK?

> Just pointing out that some assumptions about how voice call works is
> not true. Nor would it be smart to send traffic to another part of
> the world unnecessarily. Local calls stay local even when roaming.
> Please remember that signaling and voice is separate in the telco
> world which is why it compares poorly with IP. Except for the LISP
> protocol which does something similar.

I'm afraid you have too much complicated view on phone networks
and the Internet.

Masataka Ohta

Comcast Customer Owned Modem Firmware : WAS : Xfi Advances Security (comcast)

[Tom Beecher]

Jason-

I have a sidebar question here.

I came across the AQM paper you and others recently published. (
https://arxiv.org/pdf/2107.13968.pdf ) In that paper, the following is
stated :

When a customer purchases their own cable modem, they are responsible for
> administering it, updating the software, configuring it, replacing it if it
> fails, and so on. These modems are generally referred to as Consumer Owned
> And Managed (COAM) devices.



> An important distinction between leased and COAM modems is support for the
> operating firmware. For COAM devices, the modem’s operating firmware is
> provided by the modem’s manufacturer, who controls the feature set, bug
> fixes, and firmware release schedule (to the extent that there even are any
> post-sale software updates).


Does Comcast actually allow customers who own their own modems full
management of the modem firmware? As far as I have been aware since my time
at Adelphia 20-odd years ago, that has never been allowed by provider; all
users of a given model had the same firmware enforced, customer owned or
leased didn't matter.

On Mon, Sep 13, 2021 at 5:58 PM Livingood, Jason via NANOG 
wrote:
>
> On 9/13/21, 12:02, "Owen DeLong"  wrote:
> > Yes, but it’s tragically opt-out instead of opt-in as it should be.
>
> It is not a default for an Internet access service. It comes bundled as
one of several features in an optional add on service. See
https://www.xfinity.com/learn/internet-service/modems-and-routers for
details. This is targeted at the average consumer, particularly those that
may want parental controls, mesh WiFi, a voice port, and so on - so not
really targeted at NANOG list subs like us. ;-) That said, I have an XB7
modem at home and really like it a lot - especially the new AQM feature
that dramatically lowered working latency.
>
> > That means that anyone whose site happens to get miscategorized by them
gets the added costs of dealing with the user complaints instead of Comcast
having to bear the costs of their error.
>
> As my other reply noted, this service uses a bunch of 3rd party services
and it is those 3rd parties that maintain the lists (a la anti-spam and
anti-phishing email list vendors). So if an IP/FQDN/URL happens to be on
"our" list it is very likely getting filtered/blocked in a lot of network
places because it is on a well-known independent list.
>
> BUT, how do we know that was even the case here? Do we have a traceroute
or a screen shot of an error or block message? We seem to have concluded it
was blocked by a content filter but what technical evidence do we have
(that can help troubleshoot)? I know you are not the OP (it is Chris) - but
I'd love to know more technical detail and I am in communication off-list
with the OP (along with my colleague Tony Tauber, who was the first to
reach out to Chris 1:1).
>
> Jason
>
>
>

Re: IPv6 woes - RFC

[John Curran]

On 16 Sep 2021, at 8:58 AM, Eliot Lear  wrote:
> 
> John you were not the "sole network operator" on the directorate.[1]   
> https://www.sobco.com/ipng/directorate.minutes/bigten.5.19.94 
> 
Eliot -

You are referencing the minutes of a rather large workshop (the Big10 confab) 
that had far more attendees that the IPng Directorate itself.

The list of directorate members is contained in RFC  1752 "The Recommendation 
for the IP Next Generation Protocol” in Appendix B, and is listed below for 
reference –

Appendix B - IPng Area Directorate

   J. Allard - Microsoft   
   Steve Bellovin  - AT  
   Jim Bound  - Digital
   Ross Callon  - Wellfleet
   Brian Carpenter  - CERN 
   Dave Clark  - MIT   
   John Curran  - NEARNET  
   Steve Deering  - Xerox  
   Dino Farinacci  - Cisco 
   Paul Francis - NTT  
   Eric Fleischmann  - Boeing  
   Mark Knopper - Ameritech
   Greg Minshall  - Novell 
   Rob Ullmann - Lotus 
   Lixia Zhang  - Xerox

> And I'm not saying that there weren't arguments, but I am saying that nobody 
> said, “wait for something better.”  Rather, everyone was arguing for their 
> preferred approach out of the ones I mentioned.
> 

Also incorrect. The preferred transition approached of the recommended IPng 
candidate (SIPP) was IPAE, and that was actually dead-on-arrival.   Per the 
same recommendation RFC -

   The biggest problem the reviewers had with SIPP was with IPAE, SIPP's
   transition plan.  The overwhelming feeling was that IPAE is fatally
   flawed and could not be made to work reliably in an operational
   Internet.

This is what lead to the conception of the infamous Simple SIPP Transition 
(SST) approach as a stand-in Transition plan in order to allow for a decision 
to be made – and creation of IETF working groups to develop the respective 
transition mechanisms.  At the time of the IPng decision there was actually 
_no_ “transition plan” – as the very mechanisms that were to be used (and that 
were eventually discarded as unworkable) were just placeholders for future IETF 
work.

Thanks,
/John

p.s. My views alone.  Warning: contents may be hot / burn hazard





signature.asc
Description: Message signed with OpenPGP

Re: IPv6 woes - RFC

[Masataka Ohta]

Owen DeLong wrote:


You mean anywhere in the world. Calls to my number reach my cell phone no
matter where I go.


You are confusing number portability and call forwarding.



Not exactly… He is confusing number portability and roaming.


Wrong.

Mobility including, but not limited to, roaming (international
roaming of mobile phones is assumed) needs

1) access foreign environment

2) route packets to foreign network

Roaming today perform 1) by foreign network (often through
a chain of AAA) and 2) by home carrier as call forwarding, which
is very similar to IP mobility.

As we are talking about "Calls to my number reach my cell phone",
"call forwarding" is the most properly scoped explanation.

It should be noted that many on this thread misunderstand that
2) destroys route aggregation. However, call forwarding from
home carrier for roaming and mobility tunnel from home agent
for IP mobility is performed by end system without burdening
routing system of intermediate network and just scale.

Instead, many have wrongly assumed a poor alternative
to have a separate routing table entry for each mobile host
in global routing table, which does not scale.

Masataka Ohta

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 16, 2021, at 06:35 , Jared Mauch  wrote:
> 
> 
> 
>> On Sep 16, 2021, at 9:23 AM, Ca By  wrote:
>> 
>> 
>> 
>> 
>> This has nothing to do with IPv6, of course, other than that modern phones 
>> use
>> VoLTE so within a mobile carrier's network your voice call is probably 
>> handled
>> using IPv6 transport.
>> 
>> Good point John. 
>> 
>> A lot of folks missed that ipv6 absorbed the scale growth in mobile, and 
>> mobile is what most eyeballs and be big content consider the internet to be. 
>> And, yes, mobile voice is called VoLTE and is most commonly deployed in the 
>> usa with ipv6. 
>> 
>> And most internet is called youtube / fb, and that is ipv6 too. 
>> 
>> This is where i live and work , 87% of mobiles on v6, voice and data
>> 
>> https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/CombinedUSMobileCarriers.png
>> 
>> This is where nanog seems to be (old man yells at cloud meme)
>> 
>> https://static.wikia.nocookie.net/memepediadankmemes/images/0/01/297.jpg/revision/latest?cb=20180908193511
>> 
>> I don’t see the failure of ipv6 in 2021. It is globally deployed, providing 
>> global address, to billions of things and PB/s of content 
>> 
>> There are laggards in adopting v6, but they have not stopped the frontier of 
>> internet to reaching billions of people and things. 
>> 
> 
> 
> Yeah, I think this is the thing that I see people most often missing.  Yes 
> your provider may not be doing IPv6, but many applications and providers may 
> yet be IPv6 internally or IPv6 to the popular content. 
> 
> I also say the number of people who store an IP as integer in a 
> mysql(mariadb) backend is not to be underestimated.  

Nothing wrong with this as long as it’s a 128 bit integer. ;-)

> I still see some people doing the split up the IPv6 to store it in multiple 
> columns thing even in 2021 which is disappointing as it shows this 
> backwards/legacy thinking.

UGH… I haven’t seen that in a while, sad to hear it’s still going on.

Owen

Re: IPv6 woes - RFC

[Jared Mauch]

> On Sep 16, 2021, at 9:23 AM, Ca By  wrote:
> 
> 
> 
> 
> This has nothing to do with IPv6, of course, other than that modern phones use
> VoLTE so within a mobile carrier's network your voice call is probably handled
> using IPv6 transport.
> 
> Good point John. 
> 
> A lot of folks missed that ipv6 absorbed the scale growth in mobile, and 
> mobile is what most eyeballs and be big content consider the internet to be. 
> And, yes, mobile voice is called VoLTE and is most commonly deployed in the 
> usa with ipv6. 
> 
> And most internet is called youtube / fb, and that is ipv6 too. 
> 
> This is where i live and work , 87% of mobiles on v6, voice and data
> 
> https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/CombinedUSMobileCarriers.png
> 
> This is where nanog seems to be (old man yells at cloud meme)
> 
> https://static.wikia.nocookie.net/memepediadankmemes/images/0/01/297.jpg/revision/latest?cb=20180908193511
> 
> I don’t see the failure of ipv6 in 2021. It is globally deployed, providing 
> global address, to billions of things and PB/s of content 
> 
> There are laggards in adopting v6, but they have not stopped the frontier of 
> internet to reaching billions of people and things. 
> 


Yeah, I think this is the thing that I see people most often missing.  Yes your 
provider may not be doing IPv6, but many applications and providers may yet be 
IPv6 internally or IPv6 to the popular content. 

I also say the number of people who store an IP as integer in a mysql(mariadb) 
backend is not to be underestimated.  

I still see some people doing the split up the IPv6 to store it in multiple 
columns thing even in 2021 which is disappointing as it shows this 
backwards/legacy thinking.

If you’re seeing majority IPv4 bits, you likely have some choke point (CGN/FW) 
or similar gateway on the content side that needs a major update.  I saw a post 
yesterday that someone used a unicode char to add an account nickname at their 
bank and it caused the entire bank to pause and them to get a phone call.  Not 
sure if it’s true, but it rings true.

Be the one enabling the next-generation access and you’ll similarly see graphs 
like the mobile carriers see.

- Jared

Re: Never push the Big Red Button

[Robert Taylor]

We had a new fire suppression guy testing our system for our computer room,
and unbeknownst to him, one of the tests that he did triggered the EPO.
One of my co-workers was in the room, which had about 20 racks of
equipment, and he told me afterwards that for a quick second he thought he
died.
He said that that going from all that noise to eerie quiet was very
disconcerting.

rgt

On Wed, Sep 15, 2021 at 7:51 PM Billy Croan 
wrote:

> Indeed. Few sounds in the data center haunt me quite as much as a
> sensation that the decibel level has just decreased significantly.
>
> On Wed, Sep 15, 2021, 4:14 PM Keith Stokes  wrote:
>
>> The bigger thing to notice is the *lack* of noise as every server, switch
>> and storage system spins down.
>>
>> ---
>>
>> Keith Stokes
>>
>>
>>
>> On Sep 15, 2021, at 3:50 PM, Stephen Satchell  wrote:
>>
>> In the data centers I've worked in over the decades, those Big Red
>> Buttons would activate a normally-closed contactor in a breaker panel. When
>> pushed, the contactor would open, and turn off all the circults in said
>> breaker panel.  Not affected are lights, convenience outlets, door locks,
>> and other non-data loads.  Resetting the contactor to the working position
>> was done after throwing all the breakers to the off position, and then turn
>> on each breaker, one at a time.
>>
>> The only noise that I have ever heard when the Big Red Button was pushed
>> was the loud BANG as the contactor operated.  You hear a similar bang in
>> movies in scenes where lights in a large area are turned on and off.
>>
>> Nothing like the BANG of a 600-amp 3-phase breaker tripping --
>> experienced that at University of Illinois Center for Advanced
>> Computation.  You immediately look for the person holding a gun.
>>
>>
>>

Re: IPv6 woes - RFC

[Ca By]

>
>
>
>
> This has nothing to do with IPv6, of course, other than that modern phones
> use
> VoLTE so within a mobile carrier's network your voice call is probably
> handled
> using IPv6 transport.
>
> Good point John.

A lot of folks missed that ipv6 absorbed the scale growth in mobile, and
mobile is what most eyeballs and be big content consider the internet to
be. And, yes, mobile voice is called VoLTE and is most commonly deployed in
the usa with ipv6.

And most internet is called youtube / fb, and that is ipv6 too.

This is where i live and work , 87% of mobiles on v6, voice and data

https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/CombinedUSMobileCarriers.png

This is where nanog seems to be (old man yells at cloud meme)

https://static.wikia.nocookie.net/memepediadankmemes/images/0/01/297.jpg/revision/latest?cb=20180908193511

I don’t see the failure of ipv6 in 2021. It is globally deployed, providing
global address, to billions of things and PB/s of content

There are laggards in adopting v6, but they have not stopped the frontier
of internet to reaching billions of people and things.

Re: IPv6 woes - RFC

[Eliot Lear]

John you were not the "sole network operator" on the directorate.[1]  
And I'm not saying that there weren't arguments, but I am saying that 
nobody said, “wait for something better.” Rather, everyone was arguing 
for their preferred approach out of the ones I mentioned.


Eliot

[1] https://www.sobco.com/ipng/directorate.minutes/bigten.5.19.94


On 16.09.21 14:10, John Curran wrote:
On 16 Sep 2021, at 5:46 AM, Eliot Lear > wrote:
It's hard to argue that there was no transition plan.  There were in 
fact at least three transition plans for the selected approach (dual 
stack, 6to4, and tunneling) some of which have been discarded along 
the way; while others came to be based on operational experience. 
Moreover, the only way to really know that a transition mechanism is 
really going to work is to let it out of the lab.  And ALL of the 
proposals would have suffered the very same transition pains, because 
just as Jeroen has pointed out, the pain stretched all the way to the 
application.


Eliot -

The requirement was not for the assertion of multiple “transition 
plans”, but rather "The protocol must have a straightforward 
transition plan from the current IPv4.”


"A straightforward plan” – singular.  If you have a link to that plan, 
please provide it, but until such time I’ll stay with my understanding 
of events (that being that we completely dropped the ball with regard 
to providing the operator community with a meaningful transition plan.)


I don't think it's reasonable to argue that we should have waited for 
some other mythical better proposal to come along.  I don't recall 
anyone arguing for that at the time, and there's no reason to believe 
that such a mythical proposal would have ever come to be in any 
foreseeable time frame.  In fact Erik Fair, Dave Crocker, Tom Kessler 
and I argued the very opposite, that we were digging ourselves a hole 
with NAT.  Your argument at the time (Interop '95, Vegas) was that 
the IETF didn't have the right to dictate address usage to 
deployments.  True enough, but then people shouldn't hang their woes 
on the IETF.


Sorry, I was on the IPng Directorate, and there were indeed arguments 
that we lacked meaningful transition strategy, and that the fig leaf 
of shipping the responsibility off to “to-be-defined” working groups 
was irresponsible.


As I mentioned earlier, the fundamental issue was that there were no 
ng proposals that were in fact substitutable resources for v4, and 
NAT was. From there, economics has ruled, arguments be damned.


As predicted - "As currently envisioned, IPng may not be ambitious 
enough in the delivery of new capabilities to compete against IPv4 and 
the inevitable arrival of network address translation devices.  In 
order to meet the requirement for “viability in the marketplace', IPng 
needs to deliver clearly improved functionality over IPv4 while 
offering some form transparent access between the IPv4 and IPng 
communities once IPv4 address depletion has occurred.”


Sorry, but as the sole “network operator” on the IPng Directorate who 
lived through thru convenient papering over of the transition 
requirement firsthand, I’ll have to concur with Randy Bush’s take on 
this one -


"real compatibility with ipv4 was disdained.  the transition plan 
was dual stack and v4 would go away in a handful of years.  the 93 
transition mechanisms were desperate add-ons when v4 did not go 
away. and dual stack does not scale, as it requires v4 space 
proportional to deployed v6 space."


we are left to make the mess work for the users, while being 
excoriated for not doing it quickly or well enough, and for trying 
to make ends meet financially.”


Anyone who wants to argue that IPng had a viable transition plan best 
put a hard link to the documented plan in their reply - trying to 
argue the point without actually citing the alleged  “straightforward 
plan" is just embarrassing.


Thanks,
/John

p.s.  Disclaimer: my views alone (although likely shared by many 
operators upon hearing silence in response to the question:  “Okay, 
how is this transition really supposed to work?”)





OpenPGP_0x87B66B46D9D27A33_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Never push the Big Red Button (New York City subway failure)

[richey goldberg]

I once worked for a provider who had a company next door that ran a small 
datacenter of about a dozen or so racks.They had been sold and all of their 
infrastructure had been virtualized and moved to the new owner’s network.
The last task of the local admin was to just get rid of everything.   They 
didn’t care how just get it gone.So he came over and asked us to come take 
a look and we could have anything we wanted.I picked up a few servers for 
lab a bunch of racks and stuff.

While we were working I asked the guy  “So there is absolutely nothing that’s 
in production in here anymore?”He said “Yep” so I asked “Then if the power 
went off in here it wouldn’t be a big deal”   and he said “Not at all”.Then 
I asked “Can I hit the red button?”He said “Sure, I always wondered what 
happened”. I hit the button and with a loud booming sound the room went 
dead silent and then the UPS started beeping.  It was at that moment 
everyone realized that you just don’t pull the button out to restart the room.  
It took us 20 minutes to figure out how to turn it all back on.

And with that when I got back to our office I made sure someone knew how to 
restart everything if we ever had to hit our red button.


-richey

From: NANOG  on behalf of 
Roy 
Date: Thursday, September 16, 2021 at 12:41 AM
To: nanog 
Subject: Re: Never push the Big Red Button (New York City subway failure)
Miy story in the late 1970s I was working in a large computer facility
with both mainframes and mil-spec 400hz computers.
Management decided that the EPO should be tested.  So we powered down
the disk and tapes.  The electrician pressed
the EPO button and NOTHING.  Everything kept running.

Turns out a wire had come loose and the fuse in the EPO circuit had blown.

Roy

Re: IPv6 woes - RFC

[John Curran]

On 16 Sep 2021, at 5:46 AM, Eliot Lear  wrote:
> It's hard to argue that there was no transition plan.  There were in fact at 
> least three transition plans for the selected approach (dual stack, 6to4, and 
> tunneling) some of which have been discarded along the way; while others came 
> to be based on operational experience.  Moreover, the only way to really know 
> that a transition mechanism is really going to work is to let it out of the 
> lab.  And ALL of the proposals would have suffered the very same transition 
> pains, because just as Jeroen has pointed out, the pain stretched all the way 
> to the application.

Eliot -

The requirement was not for the assertion of multiple “transition plans”, but 
rather "The protocol must have a straightforward transition plan from the 
current IPv4.”

"A straightforward plan” – singular.  If you have a link to that plan, please 
provide it, but until such time I’ll stay with my understanding of events (that 
being that we completely dropped the ball with regard to providing the operator 
community with a meaningful transition plan.)
> I don't think it's reasonable to argue that we should have waited for some 
> other mythical better proposal to come along.  I don't recall anyone arguing 
> for that at the time, and there's no reason to believe that such a mythical 
> proposal would have ever come to be in any foreseeable time frame.  In fact 
> Erik Fair, Dave Crocker, Tom Kessler and I argued the very opposite, that we 
> were digging ourselves a hole with NAT.  Your argument at the time (Interop 
> '95, Vegas) was that the IETF didn't have the right to dictate address usage 
> to deployments.  True enough, but then people shouldn't hang their woes on 
> the IETF.
> 
Sorry, I was on the IPng Directorate, and there were indeed arguments that we 
lacked meaningful transition strategy, and that the fig leaf of shipping the 
responsibility off to “to-be-defined” working groups was irresponsible.
> As I mentioned earlier, the fundamental issue was that there were no ng 
> proposals that were in fact substitutable resources for v4, and NAT was.  
> From there, economics has ruled, arguments be damned.
> 
As predicted - "As currently envisioned, IPng may not be ambitious enough in 
the delivery of new capabilities to compete against IPv4 and the inevitable 
arrival of network address translation devices.  In order to meet the 
requirement for “viability in the marketplace', IPng needs to deliver clearly 
improved functionality over IPv4 while offering some form transparent access 
between the IPv4 and IPng communities once IPv4 address depletion has occurred.”

Sorry, but as the sole “network operator” on the IPng Directorate who lived 
through thru convenient papering over of the transition requirement firsthand, 
I’ll have to concur with Randy Bush’s take on this one -

>> "real compatibility with ipv4 was disdained.  the transition plan was dual 
>> stack and v4 would go away in a handful of years.  the 93 transition 
>> mechanisms were desperate add-ons when v4 did not go away. and dual stack 
>> does not scale, as it requires v4 space proportional to deployed v6 space."
>> 
>> we are left to make the mess work for the users, while being excoriated for 
>> not doing it quickly or well enough, and for trying to make ends meet 
>> financially.”

Anyone who wants to argue that IPng had a viable transition plan best put a 
hard link to the documented plan in their reply - trying to argue the point 
without actually citing the alleged  “straightforward plan" is just 
embarrassing.

Thanks,
/John

p.s.  Disclaimer: my views alone (although likely shared by many operators upon 
hearing silence in response to the question:  “Okay, how is this transition 
really supposed to work?”)




signature.asc
Description: Message signed with OpenPGP

Re: IPv6 woes - RFC

[Eliot Lear]

It's hard to argue that there was no transition plan.  There were in 
fact at least three transition plans for the selected approach (dual 
stack, 6to4, and tunneling) some of which have been discarded along the 
way; while others came to be based on operational experience.  Moreover, 
the only way to really know that a transition mechanism is really going 
to work is to let it out of the lab.  And ALL of the proposals would 
have suffered the very same transition pains, because just as Jeroen has 
pointed out, the pain stretched all the way to the application.


I don't think it's reasonable to argue that we should have waited for 
some other mythical better proposal to come along.  I don't recall 
anyone arguing for that at the time, and there's no reason to believe 
that such a mythical proposal would have ever come to be in any 
foreseeable time frame.  In fact Erik Fair, Dave Crocker, Tom Kessler 
and I argued the very opposite, that we were digging ourselves a hole 
with NAT.  Your argument at the time (Interop '95, Vegas) was that the 
IETF didn't have the right to dictate address usage to deployments.  
True enough, but then people shouldn't hang their woes on the IETF.


As I mentioned earlier, the fundamental issue was that there were no ng 
proposals that were in fact substitutable resources for v4, and NAT 
was.  From there, economics has ruled, arguments be damned.


Eliot

* I *did* in fact posit an approach in 1992 that would have allowed for 
orderly transition such that IPv4 could continue, and that was to define 
class E addresses as extension blocks that were in fact name space 
prefixes for another IPv4 header.  It wasn't taken seriously, and 
perhaps rightly so.  This actually borrowed a page from the PSTN - most 
people communicate locally and so you would rarely use those extended 
name spaces.  This was before Paul (Tsuchiya) Francis offered PIP, which 
had a notion of Landmark Routing that also went nowhere.



On 16.09.21 11:15, John Curran wrote:
On 14 Sep 2021, at 3:46 AM, Eliot Lear > wrote:

….
There is no evidence that any other design choices on the table at 
the time would have gotten us transitioned any faster, and a lot of 
evidence and analysis that the exact opposite is more likely.


Elliot -

If by “design choices” you mean the criteria that we set forth for
the new protocol (IPng), then that’s potentially true - it’s
fairly challenging to hypothecate what impact different technical
criteria would have had on the outcome.

If by “design choices” you mean the tradeoffs accepted in
selecting a particular candidate protocol and declaring victory,
then I’d strongly disagree.  I believe that we had the appropriate
technical criteria for IPng (very nicely compiled and edited by
Craig Patridge and Frank Kastenholz in RFC1726) and then made
conscious decisions to disregard those very criteria in order to
“make a decision” & “move forward.”

All of the IPng proposals where completely deficient with respect
to transition capabilities.  In the rush to make a IPng
decision,the actual IPng Transition Criteria [1]  that mandated a
straightforward transition plan fromIPv4 was simply acknowledged
and then declared as “resolved" becausewe would
also simultaneously form some working groups to study all of
the transition requirements and made good on the transition
criteria via future deliverables...(deliverables that were
subsequently not delivered on)

The right answer would have been to formally and critically
evaluate each of the candidate protocols against the requirements
and not make any selection until candidate presented itself
that actually met the required technical criteria. Instead, IPv6
transition was left as an afterthought for the operator community
to solve, and thus the battles with the IETF on NAT-based
transition for nearly two decades to get this basic technical
requirement met.


FYI,
/John

Disclaimer: my views alone - made from 100% recycled electrons.

===  [1] The actual IPng Transition criteria (per RFC 1726) are as 
follows -


"
5.5 Transition

  CRITERION
 The protocol must have a straightforward transition plan from the
 current IPv4.

  DISCUSSION
 A smooth, orderly, transition from IPv4 to IPng is needed.  If we
 can't transition to the new protocol, then no matter how wonderful
 it is, we'll never get to it.

 We believe that it is not possible to have a "flag-day" form of
 transition in which all hosts and routers must change over at
 once. The size, complexity, and distributed administration of the
 Internet make such a cutover impossible.

 Rather, IPng will need to co-exist with IPv4 for some period of
 time.  There are a number of ways to achieve this co-existence
 such as requiring hosts to support two stacks, converting between
 protocols, or using 

Re: IPv6 woes - RFC

[Carsten Bormann]

On 2021-09-16, at 01:20, Michael Thomas  wrote:
> 
> So I'm beginning to think that the reason ipv6 didn't take off is one simple 
> thing: time. 

Well, actually, the reason was: Microsoft :-)
(And time.)

We entered into the current trajectory when we missed the window to get IPv6 
into Windows 95.  The rest is history…

Grüße, Carsten

Re: IPv6 woes - RFC

[Jeroen Massar via NANOG]

> On 20210916, at 11:15, John Curran  wrote:
> 
> On 14 Sep 2021, at 3:46 AM, Eliot Lear  wrote:
>> ….
>> There is no evidence that any other design choices on the table at the time 
>> would have gotten us transitioned any faster, and a lot of evidence and 
>> analysis that the exact opposite is more likely.  
> 
> Elliot - 
> 
> If by “design choices” you mean the criteria that we set forth for the new 
> protocol (IPng), then that’s potentially true - it’s fairly challenging to 
> hypothecate what impact different technical criteria would have had on the 
> outcome. 
> 
> If by “design choices” you mean the tradeoffs accepted in selecting a 
> particular candidate protocol and declaring victory, then I’d strongly 
> disagree.  I believe that we had the appropriate technical criteria for IPng 
> (very nicely compiled and edited by Craig Patridge and Frank Kastenholz in 
> RFC1726) and then made conscious decisions to disregard those very criteria 
> in order to “make a decision” & “move forward.”
> 
> All of the IPng proposals where completely deficient with respect to 
> transition capabilities.

Would not have mattered: one has to upgrade a large portion of the 
code/hardware present in the network anyway.

And ~1995 was a completely different time from 1998, or 2001 let alone 2021 in 
number of devices and deployment; thus anything one would have guessed would 
have been off.

The only thing that might have worked is a flag day, but unless some large org 
sets that in the near future, we'll just have the very very slow death thing 
that is happening and I bet that IPv4 will nicely outlive us all on this list 
and the ones that where there when IPng started.

Greets,
 Jeroen

Re: IPv6 woes - RFC

[John Curran]

On 14 Sep 2021, at 3:46 AM, Eliot Lear  wrote:
> ….
> There is no evidence that any other design choices on the table at the time 
> would have gotten us transitioned any faster, and a lot of evidence and 
> analysis that the exact opposite is more likely.

Elliot -

If by “design choices” you mean the criteria that we set forth for the new 
protocol (IPng), then that’s potentially true - it’s fairly challenging to 
hypothecate what impact different technical criteria would have had on the 
outcome.

If by “design choices” you mean the tradeoffs accepted in selecting a 
particular candidate protocol and declaring victory, then I’d strongly 
disagree.  I believe that we had the appropriate technical criteria for IPng 
(very nicely compiled and edited by Craig Patridge and Frank Kastenholz in 
RFC1726) and then made conscious decisions to disregard those very criteria in 
order to “make a decision” & “move forward.”

All of the IPng proposals where completely deficient with respect to transition 
capabilities.  In the rush to make a IPng decision, the actual IPng Transition 
Criteria [1]  that mandated a straightforward transition plan from IPv4 was 
simply acknowledged and then declared as “resolved" because we would also 
simultaneously form some working groups to study all of the transition 
requirements and made good on the transition criteria via future 
deliverables...(deliverables that were subsequently not delivered on)

The right answer would have been to formally and critically evaluate each of 
the candidate protocols against the requirements and not make any selection 
until candidate presented itself that actually met the required technical 
criteria.   Instead, IPv6 transition was left as an afterthought for the 
operator community to solve, and thus the battles with the IETF on NAT-based 
transition for nearly two decades to get this basic technical requirement met.

FYI,
/John

Disclaimer: my views alone - made from 100% recycled electrons.

===  [1] The actual IPng Transition criteria (per RFC 1726) are as follows -

"
5.5 Transition

  CRITERION
 The protocol must have a straightforward transition plan from the
 current IPv4.

  DISCUSSION
 A smooth, orderly, transition from IPv4 to IPng is needed.  If we
 can't transition to the new protocol, then no matter how wonderful
 it is, we'll never get to it.

 We believe that it is not possible to have a "flag-day" form of
 transition in which all hosts and routers must change over at
 once. The size, complexity, and distributed administration of the
 Internet make such a cutover impossible.

 Rather, IPng will need to co-exist with IPv4 for some period of
 time.  There are a number of ways to achieve this co-existence
 such as requiring hosts to support two stacks, converting between
 protocols, or using backward compatible extensions to IPv4.  Each
 scheme has its strengths and weaknesses, which have to be weighed.

 Furthermore, we note that, in all probability, there will be IPv4
 hosts on the Internet effectively forever.  IPng must provide
 mechanisms to allow these hosts to communicate, even after IPng
 has become the dominant network layer protocol in the Internet.

 The absence of a rational and well-defined transition plan is not
 acceptable.  Indeed, the difficulty of running a network that is
 transitioning from IPv4 to IPng must be minimized.  (A good target
 is that running a mixed IPv4-IPng network should be no more and
 preferably less difficult than running IPv4 in parallel with
 existing non-IP protocols).
"

In short:

  1) The protocol must have a straightforward transition plan
  2) A number of ways to achieve this which are to be explored
  3) IPng must provide backward-compatibility to IPv4-only hosts
  4) The absence of a well-defined transition plan is not acceptable

===


signature.asc
Description: Message signed with OpenPGP