Mailing List Archive

> On Sep 15, 2021, at 09:31 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> Baldur Norddahl 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.
>>>
>>> Not. With geographical aggregation, you may route a call
>>> *anywhere* in the destination country.
>
>> 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.
>
> Masataka Ohta

Not exactly… He is confusing number portability and roaming.

Owen

ons. 15. sep. 2021 19.37 skrev Owen DeLong via NANOG <nanog@nanog.org>:

>
>
> > On Sep 15, 2021, at 09:31 , Masataka Ohta <
> mohta@necom830.hpcl.titech.ac.jp> wrote:
> >
> > Baldur Norddahl 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.
> >>>
> >>> Not. With geographical aggregation, you may route a call
> >>> *anywhere* in the destination country.
> >
> >> 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.
> >
> > Masataka Ohta
>
> Not exactly… He is confusing number portability and roaming.
>

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

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.

Regards

Baldur

The 600 ton elephant in the room is anyone could right now sit down
and design and deploy some alternative to IPv4/IPv6 and from there
begin writing down how they did it as a series of standards documents
and encourage others to give it a try hoping for some snowball effect.

You just float it on top of the current probably IP layer tho there
are other possibilities, not too many (pick a layer.)

What much of the muttering is about is people (who never do things
like this) tend to be risk-averse and want someone or something on
high to bless and nurture their efforts.

That's what much of this discussion about some alternative to IPv6
comes down to, risk aversion, how do you know if you sat down and
began working out an alternative you'd be rewarded for your efforts.

You Don't!

Imagine if Linus Torvalds sat waiting for the POSIX committees et al
to take up his ideas for an alternative to Unix (TM). He'd still be
waiting.

Probably one of the worst problems with IPv6 is precisely the fact
that groups of people managed to ride directly on the then rapid
growth of IPv4 and turn out whatever a dozen or so strangers in
windowless hotel rooms and some email lists could agree on, including
all sorts of vested interests (e.g., router vendors and the big tech
of the day.) Clearly it wasn't completely insidious, it all kind of
works, it's just that there's been a lot of resistance to adoption
hence a sense that something's wrong.

The world is your oyster (TheWorld is mine :-)).

P.S. One might want to keep in mind a quote often attributed to Bill
Joy (one of the founders of Sun Microsystems, and a lot of other
stuff), roughly:

In order for a new technology to succeed it has to be ten times
better than what it seeks to replace (i.e., to overcome incumbency
and inertia.)

--
-Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD
The World: Since 1989 | A Public Information Utility | *oo*

It appears that Baldur Norddahl <baldur.norddahl@gmail.com> said:
According to Baldur Norddahl <baldur.norddahl@gmail.com>:
>> Number portability database is looked up after the call
>> reaches the destination country, which will be used for
>> further intra-national routing, which do not affect
>> country-wise aggregation of international routing table.
>
>Actually the GSM system will query the HLR to find out where to really
>route the call. Much like LISP actually.

With a century and a half of history, the phone system has a lot of different
numbering hacks.

In the US, the country is divided into several hundred regions within which
you can port phone numbers. They do this with an overlay database; on each
call the number is looked up to get a routing number which is used to route
the call. If the number hasn't been ported the routing number is the
number itself, otherwise it's a number assigned to the switch that handles
the call. The routing numbers are assigned in the familar hierarchical
way and the first seven digits of the number (three digit area code,
three digit prefix, one digit subprefix) to route the call. Mobile carriers
have their own system underneath that so if you, say, get an AT&T number in
New York, port it to Verizon, and then move to California, calls to your
number get routed to New York, looked up in the porting database, delivered
to a Verizon switch in NY, then routed within the Verizon network to your
phone in California. Dunno whether Verizon uses the same HLR to do international
roaming or separate for domestic and international.

There is a proposal to provide national number portability in the US which
would in effect merge all of the regions together and get rid of all long
distance charges within the US that has a reasonably good chance of happening.

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.

----- On Sep 15, 2021, at 2:20 PM, bzs@theworld.com wrote:

Hi,

> The 600 ton elephant in the room is anyone could right now sit down
> and design and deploy some alternative to IPv4/IPv6 and from there
> begin writing down how they did it as a series of standards documents
> and encourage others to give it a try hoping for some snowball effect.

Isn't that how 6RD (RFC5969) was created?

Thanks,

Sabri

On 9/14/21 12:44 AM, Eliot Lear wrote:
>
> There were four proposals for the IPng:
>
> * NIMROD, PIP, SIP, and TUBA
>
> SIP was the one that was chosen, supported by endpoint manufacturers
> such as Sun and SGI, and it was the MOST compatible.  Operators and
> router manufacturers at the time pushed TUBA, which was considerably
> less compatible with the concepts used in v4 because of variable
> length addressing.   If we endpoints had some notion that v6 would
> take as long as it has to diffuse, perhaps we all might have thought
> differently. I don't know.
>
>
So I'm beginning to think that the reason ipv6 didn't take off is one
simple thing: time. All of the infighting took years and by then that
ship had long sailed. The basic mechanisms for v6 for hosts were not
complicated and all of the second system syndrome fluff could be mostly
be ignored or implemented when it actually made sense. If this had been
settled within a year instead of five, there may have been a chance
especially since specialized hardware was either nonexistent or just
coming on the scene. I mean, Kalpana was still pretty new when a lot of
this was being first discussed from what I can tell. Maybe somebody else
knows when hardware routing came on the scene but there was still lots
of software forwarding planes when I started at Cisco in 1998 just as
broadband was starting to flow.

The IETF was a victim of its own dysfunction, film at 11 and now we're
having a 30 year reunion.

Mike

> On Sep 15, 2021, at 16:20 , Michael Thomas <mike@mtcc.com> wrote:
>
>
>
> On 9/14/21 12:44 AM, Eliot Lear wrote:
>>
>> There were four proposals for the IPng:
>>
>> NIMROD, PIP, SIP, and TUBA
>> SIP was the one that was chosen, supported by endpoint manufacturers such as Sun and SGI, and it was the MOST compatible. Operators and router manufacturers at the time pushed TUBA, which was considerably less compatible with the concepts used in v4 because of variable length addressing. If we endpoints had some notion that v6 would take as long as it has to diffuse, perhaps we all might have thought differently. I don't know.
>>
>>
> So I'm beginning to think that the reason ipv6 didn't take off is one simple thing: time. All of the infighting took years and by then that ship had long sailed. The basic mechanisms for v6 for hosts were not complicated and all of the second system syndrome fluff could be mostly be ignored or implemented when it actually made sense. If this had been settled within a year instead of five, there may have been a chance especially since specialized hardware was either nonexistent or just coming on the scene. I mean, Kalpana was still pretty new when a lot of this was being first discussed from what I can tell. Maybe somebody else knows when hardware routing came on the scene but there was still lots of software forwarding planes when I started at Cisco in 1998 just as broadband was starting to flow.
>
Most of it was settled fairly quickly, actually. The bigger delays were software vendors, network infrastructure product vendors (DSLAMs and the like), etc. who even after it was well settled simply didn’t feel a need to incorporate it into their products until about a year after IANA runout.
> The IETF was a victim of its own dysfunction, film at 11 and now we're having a 30 year reunion.
>
I’m not sure we can put all (or even most) of the blame on IETF dysfunction here. Don’t get me wrong, IMHO there’s plenty of IETF dysfunction and it is partially responsible. However, I suspect that if IETF had rolled out the model of perfection and an ideal protocol 1 month after the IPNG working group started, we’d still be pretty much where we are today because of the procrastination model of addressing major transitions that is baked into human nature.

Owen

On 9/15/21 4:26 PM, Owen DeLong wrote:
>
>
>> On Sep 15, 2021, at 16:20 , Michael Thomas <mike@mtcc.com
>> <mailto:mike@mtcc.com>> wrote:
>>
>>
>> On 9/14/21 12:44 AM, Eliot Lear wrote:
>>>
>>> There were four proposals for the IPng:
>>>
>>> * NIMROD, PIP, SIP, and TUBA
>>>
>>> SIP was the one that was chosen, supported by endpoint manufacturers
>>> such as Sun and SGI, and it was the MOST compatible.  Operators and
>>> router manufacturers at the time pushed TUBA, which was considerably
>>> less compatible with the concepts used in v4 because of variable
>>> length addressing.   If we endpoints had some notion that v6 would
>>> take as long as it has to diffuse, perhaps we all might have thought
>>> differently.  I don't know.
>>>
>>>
>> So I'm beginning to think that the reason ipv6 didn't take off is one
>> simple thing: time. All of the infighting took years and by then that
>> ship had long sailed. The basic mechanisms for v6 for hosts were not
>> complicated and all of the second system syndrome fluff could be
>> mostly be ignored or implemented when it actually made sense. If this
>> had been settled within a year instead of five, there may have been a
>> chance especially since specialized hardware was either nonexistent
>> or just coming on the scene. I mean, Kalpana was still pretty new
>> when a lot of this was being first discussed from what I can tell.
>> Maybe somebody else knows when hardware routing came on the scene but
>> there was still lots of software forwarding planes when I started at
>> Cisco in 1998 just as broadband was starting to flow.
>>
> Most of it was settled fairly quickly, actually. The bigger delays
> were software vendors, network infrastructure product vendors (DSLAMs
> and the like), etc. who even after it was well settled simply didn’t
> feel a need to incorporate it into their products until about a year
> after IANA runout.

I was aware of ipv6 -- or at least what would become ipv6 -- in either
1992 and absolutely no later than 1993. The internet was still tiny then
and I don't even think that CIDR was even a thing yet, and broadband was
still 5 years away. Had something simple like ipv6 headers, AAAA, and
the silliness of SLAC vs. DHCP wars had been resolved quickly there was
a very good chance that vendors would have adopted it if customers
wanted it or could be cajoled into wanting it. At that time IP was still
"the path to OSI" iirc so none of this was in cement from a vendor
standpoint (and sorry, there are lots more vendors than just router
vendors). But the entire thing dragged on and on and on and by then it
was far too late. Then the invention of NAT sealed that fate.


>> The IETF was a victim of its own dysfunction, film at 11 and now
>> we're having a 30 year reunion.
>>
> I’m not sure we can put all (or even most) of the blame on IETF
> dysfunction here. Don’t get me wrong, IMHO there’s plenty of IETF
> dysfunction and it is partially responsible. However, I suspect that
> if IETF had rolled out the model of perfection and an ideal protocol 1
> month after the IPNG working group started, we’d still be pretty much
> where we are today because of the procrastination model of addressing
> major transitions that is baked into human nature.
>
No I think the best was the enemy of the good. As it ever were. Nobody
seems to have appreciated what the real problem was -- time. Hindsight
is 20/20 but it wasn't hard to see that the internet was exploding and
wasn't in fact the "path to OSI" and by ignoring time there wasn't going
to be a path to anything.

Mike

On September 15, 2021 at 15:40 sabri@cluecentral.net (Sabri Berisha) wrote:
> ----- On Sep 15, 2021, at 2:20 PM, bzs@theworld.com wrote:
>
> Hi,
>
> > The 600 ton elephant in the room is anyone could right now sit down
> > and design and deploy some alternative to IPv4/IPv6 and from there
> > begin writing down how they did it as a series of standards documents
> > and encourage others to give it a try hoping for some snowball effect.
>
> Isn't that how 6RD (RFC5969) was created?
>
> Thanks,
>
> Sabri

One could use a similar approach tho probably an entire routing
infrastructure would also need to be simulated. It wouldn't just be
sneaking a packet from here to there, it would be the emulation of an
entire network most likely. Hard to say w/o a design spec :-)

But at the end of the day it's just bits.

--
-Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD
The World: Since 1989 | A Public Information Utility | *oo*

On 14 Sep 2021, at 3:46 AM, Eliot Lear <lear@ofcourseimright.com> 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

===

> On 20210916, at 11:15, John Curran <jcurran@istaff.org> wrote:
>
> On 14 Sep 2021, at 3:46 AM, Eliot Lear <lear@ofcourseimright.com> 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

On 2021-09-16, at 01:20, Michael Thomas <mike@mtcc.com> 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

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 <lear@ofcourseimright.com
> <mailto:lear@ofcourseimright.com>> 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 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
>
> ===

On 16 Sep 2021, at 5:46 AM, Eliot Lear <lear@ofcourseimright.com> 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?”)

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 <lear@ofcourseimright.com
> <mailto:lear@ofcourseimright.com>> 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?”)
>
>

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

> On Sep 16, 2021, at 9:23 AM, Ca By <cb.list6@gmail.com> 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

> On Sep 16, 2021, at 06:35 , Jared Mauch <jared@puck.nether.net> wrote:
>
>
>
>> On Sep 16, 2021, at 9:23 AM, Ca By <cb.list6@gmail.com> 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

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$B!D(B 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

On 16 Sep 2021, at 8:58 AM, Eliot Lear <lear@ofcourseimright.com> wrote:
>
> John you were not the "sole network operator" on the directorate.[1] https://www.sobco.com/ipng/directorate.minutes/bigten.5.19.94 <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 <jallard@microsoft.com>
Steve Bellovin - AT&T <smb@research.att.com>
Jim Bound - Digital <bound@zk3.dec.com>
Ross Callon - Wellfleet <rcallon@wellfleet.com>
Brian Carpenter - CERN <brian.carpenter@cern.ch>
Dave Clark - MIT <ddc@lcs.mit.edu >
John Curran - NEARNET <curran@nic.near.net>
Steve Deering - Xerox <deering@parc.xerox.com>
Dino Farinacci - Cisco <dino@cisco.com>
Paul Francis - NTT <francis@slab.ntt.jp>
Eric Fleischmann - Boeing <ericf@atc.boeing.com>
Mark Knopper - Ameritech <mak@aads.com>
Greg Minshall - Novell <minshall@wc.novell.com>
Rob Ullmann - Lotus <ariel@world.std.com>
Lixia Zhang - Xerox <lixia@parc.xerox.com>

> 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

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

John Curran wrote:

> If by "design choices" you mean the tradeoffs accepted in selecting a
> particular candidate protocol and declaring victory, then I$B!G(Bd
> 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

On 16 Sep 2021, at 11:33 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> 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 - You are correct, in that the design choices made for the final “IPng" weren’t actually any of the proposals as submitted, but rather an interesting compromise creation.

(My negative answer to Eliot’s "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” was simply noting that the design choices made about the “straightforward transition plan" was effectively to punt – i.e. despite lacking one, choosing declare victory anyway and leave it as an exercise for the reader. It’s fairly obvious that different choices here could have made a very significant difference in IPng deployment trajectory.)

Thanks,
/John

Disclaimer: my views alone - (no one else would wanted them…)

your memory of the procedural details is better than mine. you have my
sympathies. i was focused on the technical disater that has cost us
decades. but folk who i still consider friends were willing to throw
dren at the wall hoping it would stick so the ietf/iana was not taking
crap in the press for the looming disaster of running out of address
space. and here we are, decades later, still having to listen to
hysteria about running out of address space; just not in the new york
times. problem solved, eh?

we had to invent dnssec to find something that would deploy more slowly,
and with more gl!tches, than ipv6.

and have you seen what's going on in the 6man wg?!?!

randy

> On Sep 11, 2021, at 13:17 , John R. Levine <johnl@iecc.com> wrote:
>
>>> Indeed. They would send postcards to all their customers saying
>>> "Comcast has said they will cut off your access to Netflix on April 1,
>>> Call their president's office at 1-800-xxx-xxxx and tell them what you think."
>>
>> Nope… Netflix is fully available on IPv6 and actually looks forward to ISPs
>> doing this.
>
> OK, then Disney+ or Hulu or whoever. Peering wars never end well. Don't even need postcards, just stick the flyer in with the bill.

Is that really cheaper and easier than deploying IPv6? Really?

>> Now Amazon might send post cards saying “Comcast has said that they
>> will cut off your access to our store…”, but I suspect that the cost of such
>> a campaign and the collateral damage would be well in excess of the
>> cost of just adding IPv6 to their service.
>
> AWS has perfectly good support for IPv6 so they must have business reasons to stick with v4. But I expect the cost of putting up banners on the homepage saying to call your ISP, for people coming through the relevant ISP, would be pretty cheap, and Amazon's customers appear to like their accounts and their Prime quite a lot. Again, peering wars never end well.

This isn’t really the same as a peering war, however. They can’t really claim Comcast is going to cut you off. They’d have to admit that Comcast is going to start charging more for…

Remember, I didn’t suggest that Comcast turn off IPv4… I suggested that Comcast start passing along some of the added expense of maintaining IPv4 connectivity to the customers that want it.

> This ignores the question of what the advantage to the ISP would be other than bloody-mindedness. The world is not going to abandon IPv4 any time soon and the last time I looked, the cost of routing packets is the same regardless of which header they have.

You haven’t looked in depth, then. The cost of routing packets is the same. The cost of dealing with address shortages and supporting/maintaining the various hacks and workarounds intended to help mitigate that issue continues to increase.

As I have repeatedly stated, the perverse incentive here that drives things is that those who lag aren’t bearing most of the costs. Instead, like toxic polluters, they are able to externalize those costs to developers, eyeball ISPs, CDNs, and others while continuing the status quo.

The flyer in the bill thing works both ways. Comcast could just as easily put in a flyer that points out the facts of the situation:

1. There is a flaw in the addressing scheme currently in use in that it doesn’t have enough addresses for everyone.
2. There is a new-iso addressing scheme that has been in use for more than 20 years now.
3. Many services are available through either addressing scheme today.
4. The cost of preserving connectivity to the old addressing scheme is continuing to increase.
5. As a result, starting on <X date in the future>, we will be passing some of those costs on to customers who still
want to use the old addressing scheme in the form of an “IPv4 Surcharge”.
6. For more details and to see a list of popular services that do and don’t currently work with the new addressing scheme,
check <link>here</link>.

If the surcharge starts out at something silly like $2/month or even $5/month, I bet most customers just pay it.

Large chunks of the world (those that have IPv6 deployed) would love to abandon or mostly abandon IPv4 as soon
as possible. That possibility isn’t defined as “when everybody has IPv6”. It’s defined (for at least eyeball ISPs) as
“When enough of the content providers our customers care about are on IPv6 that the business we lose by turning
off IPv4 costs less than maintaining IPv4 for all of our customers.”

That day may not be today, but it is coming and I don’t think it’s as far off as you imagine.

The soft way for eyeball ISPs to approach that is to start passing along some of those costs to their customers by
making IPv4 an opt-in add-on to their Internet Service with a nominal charge. Sort of like the fee I used to pay when
I had cable TV service where they charged me ~$5 every month for “access to local sports” which I didn’t want
and repeatedly asked them to stop.

Owen