Subject: Re: [Int-area] IPv10.

From: Lee Howard <[email-masked]>
Date: Fri, 01 Sep 2017 16:54:02 -0400

From:  Int-area <[email-masked]> on behalf of Khaled Omar
<[email-masked]>
Date:  Friday, September 1, 2017 at 3:16 PM
To:  int-area <[email-masked]>
Subject:  [Int-area] IPv10.

>Hi Everyone,
> 
>We still can continue the discussion of the IPv10 I-D, I’m asking all of
>you if interested to take it easy to start that discussion to participate
>through the Internet Area WG or somewhere else (Private or whatever).
>
>
>

I thought you threatened us with legal action if we ever mentioned it
again?

I’m going to respond respectfully and seriously.

>
> 
>Below you can find a link to the IPv10 I-D.
> 
>https://datatracker.ietf.org/doc/draft-omar-ipv10/
>
>
>

Detailed review below.

>
> 
>Statistics still shows slow speed of IPv6 adoption and the IPv6 only
>hosts are having a limited access to the internet resources.
>

The draft says 15% adoption as of April 2017, but the same resource
(Google) now shows over 20% adoption, four months later.
If you use a logistic adoption curve, most Internet connections will be
over IPv6 in less than two years:
https://www.vyncke.org/ipv6status/project.php?metric=p&timeforward=365&time
backward=365&country=ww

Other notes on the draft:
In several places you say “did not,” where I think “have not” is more
appropriate. For instance, “most enterprises did not do this migration”
should be “most enterprises have not done this migration.” The time to
migrate has not passed: they simply have not done it yet. Maybe they never
will, but we don’t know.

I recommend changing the list under"The recent solutions for IPv4 and IPv6
coexistence are:”
Native dual stack (IPv4 and IPv6)
Dual-stack Lite
NAT64
464xlat
MAP
(other technologies also exist, like lw6over4; they may have more specific
use cases)

“Dual stack” not “Dual stacks.”
There are two kinds of tunneling techniques: IPv4 over IPv6 (DS-Lite, 4rd,
MAP) and IPv6 over IPv4 (6rd, NAT-PMT).
NAT-PT was deprecated (except under managed circumstances) by RFC4966
"Reasons to Move the Network Address Translator - Protocol Translator
(NAT-PT) to Historic Status"

Section 3 isn’t “Advantages,” it’s the protocol description. Move the
“advantages” discussion to the end, if you keep it at all.

Section 3.1
In the packet header, you show “Data” prior to the addresses. Is it a
packet footer? I don’t understand the format. I referred to Section 4,
where it looks like a more conventional packet header, but comparing the
two it still looks like data precedes source address (at least in Section
3).

The documentation prefixes are 2001:db8:: (rfc3849) and 192.0.2.0/24,
198.51.100.0/24 and 203.0.113.0/24 (rfc5737).

How does the IPv10 sending host know the ASN and MAC of the IPv4
destination host? 
Given the concerns expressed in rfc4941 "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6” isn’t there a privacy concern with
using the MAC address?
What benefit is there in using ASN and MAC? Why not just pad with zeroes?

You have the host configuration include an IPv4 address for the DNS
Address. How will an IPv6-only how use an IPv4 DNS server? If your answer
is “IPv10” then I think there’s a bootstrap problem of how to reach the
server so you can get information needed to reach the server.

Section 3.2
This example is even clearer. In the example, the network is dual stack
all the way to the default gateway. If it were dual-stack that far, why
not dual-stack the host? Using NAT44, or any of the myriad transition
protocols available. In fact, that’s the current dual-stack scenario
(native IPv6 plus NAT44), and one which you point out is untenable as we
run out of IPv4 addresses to assign to networks. A residential ISP can’t
dual-stack a customer’s CPE when they’re out of IPv4 addresses, so how can
IPv10 work?

Further, if the network is dual-stack, why not enable dual-stack on the
host, using existing protocols? Why develop a new one, and require the
host to implement all of IPv4, IPv6, and IPv10, and then disable either
IPv4 or IPv6?

Same question as in 3.1 about the packet format, and how an IPv4 host uses
an IPv6 name server.
I understand how a host might be able to insert its MAC address into a 128
bit source address, but how does it know its ASN?
What does it do if it’s behind NAT44, as is almost universally the case?
The routers would have to be updated to recognize the IPv10 address and
translate just the IPv4 address bits, right?
Firewalls would have to be updated to recognize the IPv10 address format.

In the example, it’s confusing to have the packet going from right to
left. You’ve changed the order of the header fields, but not the bits in
the fields.

Section 3.3
Without seeing full header information, I can’t tell how this is different
than native IPv6.

Section 3.4
In addition to the questions from Section 3.2, I’m confused about why you
need IPv10 in this case, when you have two hosts that speak IPv4 and all
networks in between speak IPv4.

The “Important Notes” should be its own section.
As you point out, I cannot understand why this would be faster to deploy
than IPv6 when:
"IPv4 and IPv6 routing must be enabled on all routers”
and
"All Internet connected hosts must be IPv10 hosts”

IPv6 has a 20% head start over IPv10.
IPv10 isn’t useful until it’s 100% deployed. How will it ever catch up?

I think you’ve said in the past that IPv10 only requires software updates,
but if a header has to be parsed to decide whether to forward over IPv4 or
IPv6 (but it can’t use IPv4 because it’s not IPv4, so you have a whole new
forwarding plane to develop) it needs to be done at hardware speeds.
Punting to the route engine at Internet scale means dropping packets.

Section 4
This should come before Section 3, IMHO.

Are the Traffic Class, Flow Label, and Next Header field values identical
to IPv6 fields?

In summary:
This might be possible, with enough work, but I can’t see how it will
overtake the momentum of IPv6 deployment and existing transition
mechanisms. Here’s a possible timeline, being very generous to IPv10:
	IPv6			IPv10
2018 	50% of US		WG discussion
2019	50% of world		IETF nearing consensus (into 2020)
2021	75% of world		first vendor code ships
2026	99% of world		Old hardware that couldn’t support new code is cycling
out

You can prove me wrong:
1. Write an implementation. Show how an IPv4+IPv10 host can communicate
with an IPv6+IPv10 host over a dual-stack (or triple-stack) network. If
the router implementation is an open-source router, that’s fine at this
stage.
2. Have someone else write an implementation that interoperates with
yours. That will demonstrate that the document is detailed enough and
clear enough.
3. Do some performance testing. Show that it is easier to update to IPv10
than to dual-stack (including IPv6+transition), and that there is no
performance penalty for doing so.
4. Convince a router vendor to implement in test code, and run load
testing, to demonstrate that it works at Internet scale.

If you can get through Step 3, you may be able to get to Step 4, and if
you can do Step 4 you have a good shot at convincing other vendors to
implement. If you can get through at least Step 3, you’ll be in good shape
in looking for IETF consensus, because you’ll have running code.

While I am skeptical of this specific proposal, I wish you luck and hope
you will engage with other work in the IETF.

Lee

---

From: Khaled Omar <[email-masked]>
Date: Fri, 1 Sep 2017 22:04:12 +0000

Hi Lee,

First of all, Thanks for your detailed review.

> In several places you say “did not,” where I think “have not” is more appropriate. For instance, “most enterprises did not do this migration”
should be “most enterprises have not done this migration.” The time to migrate has not passed: they simply have not done it yet. Maybe they never will, but we don’t know.

Thanks for your review, we can replace "did not" to be "have not".

> The time to migrate has not passed: they simply have not done it yet. Maybe they never will, but we don’t know.

We can measure this from the start of asking for migration which is since IPv6 was developed, it wasn't expected that it will take this long time and there was plenty of IPv4 address space remaining.

(Google) now shows over 20% adoption, four months later.
If you use a logistic adoption curve, most Internet connections will be over IPv6 in less than two years.

I think Google measures it by counting the number of hosts accessing Google not by each enterprise where everyone enterprise is counted by +1. 

> I thought you threatened us with legal action if we ever mentioned it again?

It wasn't a threat, it was just protection for the legal rights.

> Section 3.1
In the packet header, you show “Data” prior to the addresses. Is it a packet footer? I don’t understand the format. I referred to Section 4, where it looks like a more conventional packet header, but comparing the two it still looks like data precedes source address (at least in Section 3).

You mean that "Data" should be a header not a trailer, the format on the ID shows "Data" as a segment and part of the IP packet header which is the source and destination addresses. 

> How does the IPv10 sending host know the ASN and MAC of the IPv4 destination host?

By adding the ASN to the ARP Reply for IPv4 and the RA for IPv6, where every host will store the ASN besides the router advertised information.

> isn’t there a privacy concern with using the MAC address?

This can be used for security concerns meaning "Host Identification", and the MAC address information sent in the L3 is not routable, just to identify the host.

> You have the host configuration include an IPv4 address for the DNS Address. How will an IPv6-only how use an IPv4 DNS server? If your answer is “IPv10” then I think there’s a bootstrap problem of how to reach the server so you can get information needed to reach the server.

The IPv10 host with IPv6 address will communicate directly to the DNS from the configured information, I don't understand why bootstrap problem, the communication will be accomplished directly IPv6 --> IPv4 then IPv4 --> IPv6.

> Further, if the network is dual-stack, why not enable dual-stack on the host, using existing protocols? Why develop a new one, and require the host to implement all of IPv4, IPv6, and IPv10, and then disable either
IPv4 or IPv6?

The IPv10 deployment will not change the existing configuration, IPv10 is not an IP address structure, it will only allow both IP versions to be encapsulated in the same header. 

> Same question as in 3.1 about the packet format, and how an IPv4 host uses an IPv6 name server.

The IPv4 host will communicate directly to the DNS configured IP address (it can be IPv4 or IPv6), then the DNS will resolve that name to a host A record or host AAAA record and send the IP address of the destination host which can be an IPv4 or IPv6 host.

> In addition to the questions from Section 3.2, I’m confused about why you need IPv10 in this case, when you have two hosts that speak IPv4 and all networks in between speak IPv4.
 
This just to mean that all possible communication can be accomplished. 

Correct, if all hosts will be IPv6, IPv10 will disappear automatically, but if only one host with an IPv4 address will still use all 99% of the Internet.

After all these concerns, I would like to thank you again for adding your name again to the I-D :-)

Best Regards,

Khaled Omar

-----Original Message-----
From: Lee Howard [mailto:[email-masked]] 
Sent: Friday, September 1, 2017 10:54 PM
To: Khaled Omar; int-area
Subject: Re: [Int-area] IPv10.

From:  Int-area <[email-masked]> on behalf of Khaled Omar <[email-masked]>
Date:  Friday, September 1, 2017 at 3:16 PM
To:  int-area <[email-masked]>
Subject:  [Int-area] IPv10.

>Hi Everyone,
> 
>We still can continue the discussion of the IPv10 I-D, I’m asking all 
>of you if interested to take it easy to start that discussion to 
>participate through the Internet Area WG or somewhere else (Private or whatever).
>
>
>

I thought you threatened us with legal action if we ever mentioned it again?

Detailed review below.

The draft says 15% adoption as of April 2017, but the same resource
(Google) now shows over 20% adoption, four months later.
If you use a logistic adoption curve, most Internet connections will be over IPv6 in less than two years:
https://www.vyncke.org/ipv6status/project.php?metric=p&timeforward=365&time
backward=365&country=ww

Other notes on the draft:
In several places you say “did not,” where I think “have not” is more appropriate. For instance, “most enterprises did not do this migration”
should be “most enterprises have not done this migration.” The time to migrate has not passed: they simply have not done it yet. Maybe they never will, but we don’t know.

I recommend changing the list under"The recent solutions for IPv4 and IPv6 coexistence are:”
Native dual stack (IPv4 and IPv6)
Dual-stack Lite
NAT64
464xlat
MAP
(other technologies also exist, like lw6over4; they may have more specific use cases)

NAT-PT was deprecated (except under managed circumstances) by RFC4966 "Reasons to Move the Network Address Translator - Protocol Translator

Section 3 isn’t “Advantages,” it’s the protocol description. Move the “advantages” discussion to the end, if you keep it at all.

Section 3.1
In the packet header, you show “Data” prior to the addresses. Is it a packet footer? I don’t understand the format. I referred to Section 4, where it looks like a more conventional packet header, but comparing the two it still looks like data precedes source address (at least in Section 3).

How does the IPv10 sending host know the ASN and MAC of the IPv4 destination host? 
Given the concerns expressed in rfc4941 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6” isn’t there a privacy concern with using the MAC address?
What benefit is there in using ASN and MAC? Why not just pad with zeroes?

You have the host configuration include an IPv4 address for the DNS Address. How will an IPv6-only how use an IPv4 DNS server? If your answer is “IPv10” then I think there’s a bootstrap problem of how to reach the server so you can get information needed to reach the server.

Section 3.2
This example is even clearer. In the example, the network is dual stack all the way to the default gateway. If it were dual-stack that far, why not dual-stack the host? Using NAT44, or any of the myriad transition protocols available. In fact, that’s the current dual-stack scenario (native IPv6 plus NAT44), and one which you point out is untenable as we run out of IPv4 addresses to assign to networks. A residential ISP can’t dual-stack a customer’s CPE when they’re out of IPv4 addresses, so how can
IPv10 work?

Further, if the network is dual-stack, why not enable dual-stack on the host, using existing protocols? Why develop a new one, and require the host to implement all of IPv4, IPv6, and IPv10, and then disable either
IPv4 or IPv6?

Same question as in 3.1 about the packet format, and how an IPv4 host uses an IPv6 name server.
I understand how a host might be able to insert its MAC address into a 128 bit source address, but how does it know its ASN?
What does it do if it’s behind NAT44, as is almost universally the case?
The routers would have to be updated to recognize the IPv10 address and translate just the IPv4 address bits, right?
Firewalls would have to be updated to recognize the IPv10 address format.

In the example, it’s confusing to have the packet going from right to left. You’ve changed the order of the header fields, but not the bits in the fields.

Section 3.3
Without seeing full header information, I can’t tell how this is different than native IPv6.

Section 3.4
In addition to the questions from Section 3.2, I’m confused about why you need IPv10 in this case, when you have two hosts that speak IPv4 and all networks in between speak IPv4.

The “Important Notes” should be its own section.
As you point out, I cannot understand why this would be faster to deploy than IPv6 when:
"IPv4 and IPv6 routing must be enabled on all routers”
and
"All Internet connected hosts must be IPv10 hosts”

I think you’ve said in the past that IPv10 only requires software updates, but if a header has to be parsed to decide whether to forward over IPv4 or
IPv6 (but it can’t use IPv4 because it’s not IPv4, so you have a whole new forwarding plane to develop) it needs to be done at hardware speeds.
Punting to the route engine at Internet scale means dropping packets.

Section 4

Are the Traffic Class, Flow Label, and Next Header field values identical to IPv6 fields?

In summary:
This might be possible, with enough work, but I can’t see how it will overtake the momentum of IPv6 deployment and existing transition mechanisms. Here’s a possible timeline, being very generous to IPv10:
	IPv6			IPv10

You can prove me wrong:
1. Write an implementation. Show how an IPv4+IPv10 host can communicate with an IPv6+IPv10 host over a dual-stack (or triple-stack) network. If the router implementation is an open-source router, that’s fine at this stage.
2. Have someone else write an implementation that interoperates with yours. That will demonstrate that the document is detailed enough and clear enough.
3. Do some performance testing. Show that it is easier to update to IPv10 than to dual-stack (including IPv6+transition), and that there is no performance penalty for doing so.
4. Convince a router vendor to implement in test code, and run load testing, to demonstrate that it works at Internet scale.

If you can get through Step 3, you may be able to get to Step 4, and if you can do Step 4 you have a good shot at convincing other vendors to implement. If you can get through at least Step 3, you’ll be in good shape in looking for IETF consensus, because you’ll have running code.

While I am skeptical of this specific proposal, I wish you luck and hope you will engage with other work in the IETF.

Lee

---

From: Lee Howard <[email-masked]>
Date: Fri, 01 Sep 2017 21:38:07 -0400

>name again to the I-D :-)

Leaving aside all other concerns, I have not added my name to the draft.
Please do not try again to list me as a co-author.

Lee

>migrate has not passed: they simply have not done it yet. Maybe they
>never will, but we don’t know.
>
>I understand how a host might be able to insert its MAC address into a
>128 bit source address, but how does it know its ASN?
>I think you’ve said in the past that IPv10 only requires software
>updates, but if a header has to be parsed to decide whether to forward
>over IPv4 or
>IPv6 (but it can’t use IPv4 because it’s not IPv4, so you have a whole
>new forwarding plane to develop) it needs to be done at hardware speeds.
>implement. If you can get through at least Step 3, you’ll be in good
>shape in looking for IETF consensus, because you’ll have running code.
>
>

---

From: Khaled Omar <[email-masked]>
Date: Sat, 2 Sep 2017 11:06:58 +0000

Sure thing, 

Khaled Omar

-----Original Message-----
From: Lee Howard [mailto:[email-masked]] 
Sent: Saturday, September 2, 2017 3:38 AM
To: Khaled Omar
Cc: int-area
Subject: Re: [Int-area] IPv10.

Lee

>https://www.vyncke.org/ipv6status/project.php?metric=p&timeforward=365&
>tim
>e
>backward=365&country=ww
>
>where it looks like a more conventional packet header, but comparing 
>the two it still looks like data precedes source address (at least in 
>Section 3).
>
>Given the concerns expressed in rfc4941 "Privacy Extensions for 
>Stateless Address Autoconfiguration in IPv6” isn’t there a privacy 
>concern with using the MAC address?
>Address. How will an IPv6-only how use an IPv4 DNS server? If your 
>answer is “IPv10” then I think there’s a bootstrap problem of how to 
>reach the server so you can get information needed to reach the server.
>
>
>Section 3.2
>(native IPv6 plus NAT44), and one which you point out is untenable as 
>we run out of IPv4 addresses to assign to networks. A residential ISP 
>can’t dual-stack a customer’s CPE when they’re out of IPv4 addresses, 
>so how can
>IPv10 work?
>
>left. You’ve changed the order of the header fields, but not the bits 
>in the fields.
>
>
>Section 3.3
>In addition to the questions from Section 3.2, I’m confused about why 
>you need IPv10 in this case, when you have two hosts that speak IPv4 
>and all networks in between speak IPv4.
>
>
>3. Do some performance testing. Show that it is easier to update to 
>IPv10 than to dual-stack (including IPv6+transition), and that there is 
>no performance penalty for doing so.
>While I am skeptical of this specific proposal, I wish you luck and 
>hope you will engage with other work in the IETF.
>
>Lee
>
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 28 Sep 2017 14:18:35 +0200

I agree with this.

One should be very careful with Author names.

One cant just paste someone's name in a draft.  There should be 
willingness, invitation, agreement, even retiring names some times.

This can take time, but it should happen.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 28 Sep 2017 14:35:36 +0200

Le 01/09/2017 à 22:54, Lee Howard a écrit :
[...]
> 2026	99% of world		Old hardware that couldn’t support new code is cyclin                                 out
I am very happy to see the left column.  Because it shows IPv6 adoption 
is happening on a large scale.  This is encouraging.

I would like, however, to express a risk, and at the same time, an 
opportunity of further comparison.

The points of view are very different from country to country: 50% 
penetration in US; I think Egypt is something like 0.2% penetration.  50 
is significantly bigger than 0.2.  This can be interpreted as too 
overwhelming.

Listing US vs World may also be a risk of interpretation - sounds as if 
US is not part of the world.

However, a common denominator could be: IPv6 is present (or not) in 
country x vs country y.

Then one can discuss why, in a certain Country, the IPv6 presence is 
posing problems of interconnectivity to IPv4 Internet.

Also, I agree it's hard to talk US, world, or even Country, in an 
interconnected system like Internet.

My two cents worth.

Alex

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>