Subject: Re: [Int-area] New Version Notification for draft-xu-intarea-ip-in-udp-01.txt

From: Xuxiaohu <[email-masked]>
Date: Thu, 23 Apr 2015 02:15:11 +0000

By the way, one major reason for allocating two different port numbers for IPv4 and IPv6 respectively is to protect the version field of the inner IP header (i.e., a single-bit corruption of the version field may cause v4 (0100) to become v6 (0110) and vice versa).

Best regards,
Xiaohu

> -----Original Message-----
> From: Xuxiaohu
> Sent: Thursday, April 23, 2015 9:38 AM
> To: [email-masked]
> Subject: FW: New Version Notification for draft-xu-intarea-ip-in-udp-01.txt
> 
> Hi all,
> 
> Major changes include :1) request allocating different UDP port numbers for
> IPv4 and IPv6 respectively; 2) add a new co-author.
> 
> Any comments are welcome.
> 
> Best regards,
> Xiaohu
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, April 23, 2015 9:34 AM
> > To: Lucy yong; Yiu Lee; Xuxiaohu; Yongbing Fan; Rajiv Asati; Xuxiaohu;
> > Lucy yong; Tom Herbert; Iljitsch van Beijnum; Yiu Lee; Tom Herbert;
> > Rajiv Asati; Iljitsch van Beijnum; Fan Yongbing
> > Subject: New Version Notification for
> > draft-xu-intarea-ip-in-udp-01.txt
> >
> >
> > A new version of I-D, draft-xu-intarea-ip-in-udp-01.txt has been
> > successfully submitted by Xiaohu Xu and posted to the IETF repository.
> >
> > Name:		draft-xu-intarea-ip-in-udp
> > Revision:	01
> > Title:		Encapsulating IP in UDP
> > Document date:	2015-04-22
> > Group:		Individual Submission
> > Pages:		11
> > URL:
> > http://www.ietf.org/internet-drafts/draft-xu-intarea-ip-in-udp-01.txt
> > Status:         https://datatracker.ietf.org/doc/draft-xu-intarea-ip-in-udp/
> > Htmlized:       http://tools.ietf.org/html/draft-xu-intarea-ip-in-udp-01
> > Diff:
> http://www.ietf.org/rfcdiff?url2=draft-xu-intarea-ip-in-udp-01
> >
> > Abstract:
> >    Existing Softwire encapsulation technologies are not adequate for
> >    efficient load balancing of Softwire service traffic across IP
> >    networks.  This document specifies additional Softwire encapsulation
> >    technology, referred to as IP-in-User Datagram Protocol (UDP), which
> >    can facilitate the load balancing of Softwire service traffic across
> >    IP networks.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Apr 2015 19:35:26 -0700

> On Apr 22, 2015, at 7:15 PM, Xuxiaohu <[email-masked]> wrote:
> 

The conversion to IPv4 should be caught by the header checksum ( which would be unlikely to be correct). 

And single but errors should be caught by L2 anyway. If those happen undetected you have bigger problems. 

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

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 25 Apr 2015 01:33:20 +0000

Hi Joe,

> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, April 23, 2015 10:35 AM
> To: Xuxiaohu
> Cc: [email-masked]
> Subject: Re: [Int-area] New Version Notification for
> > By the way, one major reason for allocating two different port numbers for
> IPv4 and IPv6 respectively is to protect the version field of the inner IP header
> (i.e., a single-bit corruption of the version field may cause v4 (0100) to become
> v6 (0110) and vice versa).
> 

Oh, yes, your observation is correct. However, wouldn't it be better to be consistent with the practice of having two IP protocols (IPIP 4, SIT 41), two Ethertypes, two PPP types, two VXLAN-GPE types, etc for IPv4 and IPv6 payloads respectively?

Best regards,
Xiaohu

> >>> To: Lucy yong; Yiu Lee; Xuxiaohu; Yongbing Fan; Rajiv Asati;
> >>> Xuxiaohu; Lucy yong; Tom Herbert; Iljitsch van Beijnum; Yiu Lee; Tom
> >>> Herbert; Rajiv Asati; Iljitsch van Beijnum; Fan Yongbing
> >>> Status:
> https://datatracker.ietf.org/doc/draft-xu-intarea-ip-in-udp/

---

From: Joe Touch <[email-masked]>
Date: Sat, 25 Apr 2015 00:11:35 -0700

On 4/24/2015 6:33 PM, Xuxiaohu wrote:
> Oh, yes, your observation is correct. However, wouldn't it be better
> to be consistent with the practice of having two IP protocols (IPIP 4,
> SIT 41), two Ethertypes, two PPP types, two VXLAN-GPE types, etc for
> IPv4 and IPv6 payloads respectively?

1) many "wrongs" do not make a right
(http://en.wikipedia.org/wiki/Two_wrongs_make_a_right)

2) IP has a version field for exactly this purpose

The real question, from a transport ports perspective, is whether these
are two distinct services or one, and if they are two services, why the
service header doesn't differentiate the services. E.g., see:
https://tools.ietf.org/html/draft-ietf-tsvwg-port-use-11

Without specific need for two separate ports, a single port should be
sufficient. So far, I haven't seen anything except incorrect arguments
and bad precedent as justification.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 15:10:04 +0000

Hi,

> From: Int-area [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Saturday, April 25, 2015 12:12 AM
> To: Xuxiaohu
> Cc: [email-masked]
> Subject: Re: [Int-area] New Version Notification for draft-xu-intarea-ip-in-udp-01.txt
> 
> 
> 

AERO treats the first four bits following the UDP header as a version field.
If the value is 4, then the data following the UDP header is an IPv4 header.
If the value is 6, then the data following the UDP header is an IPv6 header.
If the value is 0, then the data following the UDP header is an AERO shim
header that is formatted very similar to  Generic UDP Encapsulation (GUE).

So, why not combine this document with GUE into a single document, and
use the first four bits to determine the type of encapsulation (i.e., a 4-bit
version value)? It makes for a very modular packaging for the same reason
that IP includes a version field.

Thanks - Fred
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Apr 2015 09:02:52 -0700

On 4/27/2015 8:10 AM, Templin, Fred L wrote:
...
> header that is formatted very similar to  Generic UDP Encapsulation (GUE).

The outer (non-IP) header needs to indicate that the payload is IP.

Once it does, it needs to interpret the packet as IP. 0 is a reserved
code for IP; it might be used in the future to indicate a new IP header
format with an extended version field. As a result, assuming that a 0 is
"safe" to interpret as non-IP is incorrect - again, presuming the outer
header didn't already indicate otherwise (in which case you don't need
the "0").

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 16:14:37 +0000

Hi Joe,

> Sent: Monday, April 27, 2015 9:03 AM
> To: Templin, Fred L; Xuxiaohu
> Cc: [email-masked]

In what lifetime do you see IP version 0 being allocated (not in ours)?
Or, if it is to be allocated, then why not for this purpose?

Or, why not reuse another value that has already been clobbered
by IP protocol versions that went nowhere (e.g., 5, 7, 8, 9)?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Apr 2015 09:22:02 -0700

...
> In what lifetime do you see IP version 0 being allocated (not in ours)?

You can't know that, which is why it is incorrect to co-opt it for your
purposes.

> Or, if it is to be allocated, then why not for this purpose?

Make a proposal to do so, and get it standardized first.

> by IP protocol versions that went nowhere (e.g., 5, 7, 8, 9)?

That doesn't matter; what matters is whether "0", which is currently
reserved, is assigned for a purpose.

Don't squat and don't assume.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 16:26:46 +0000

Hi Joe,

> Sent: Monday, April 27, 2015 9:22 AM

Then, let's use one of the nullified version numbers and put it to good use.
IPv7 was allocated for RFC1475 but that is now obsoleted by RFC6814. So,
this document (if combined with GUE and then published) should be able
to claim it.

Thanks - Fred

---

From: Brian Haberman <[email-masked]>
Date: Mon, 27 Apr 2015 12:33:11 -0400

> this document (if combined with GUE and then published) should be able

No.  You simply cannot claim a number managed by an IANA registry.
Follow the rules.

Regards,
Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 16:38:08 +0000

Hi Brian,

> From: Int-area [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Monday, April 27, 2015 9:33 AM
> To: [email-masked]

The rules being to publish an RFC with an appropriate IANA Considerations
section, right? That is all I am suggesting - are there some other rules you
know of?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Apr 2015 09:47:11 -0700

> this document (if combined with GUE and then published) should be able

Again, write a standards-track doc (which is required for IP codepoints)
and make a case.

Until then, don't squat.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Apr 2015 09:49:05 -0700

> this document (if combined with GUE and then published) should be able
Fred,

This also would entail a major rework of the GUE header.

We already have proposal for GUE and GRE -in-UDP, both of these can
encapsulate IPv4, IPv6, and a bunch of other protocols (either by IP
protocol or Ethertype). In the simplest firm both of these are a
simple four byte header for IP encapsulation. So other than saving
four bytes of overhead, I don't really see any other benefits to the
what you're proposing or even in the proposal to directly encapsulate
IP in UDP. Am I missing something?

Tom

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 16:52:23 +0000

Hi Tom,

I just started a new thread on this, so I won't repeat what  I said there.

Thanks - Fred

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Monday, April 27, 2015 9:49 AM
> To: Templin, Fred L
> Cc: Joe Touch; Xuxiaohu; [email-masked]

---

From: Brian Haberman <[email-masked]>
Date: Mon, 27 Apr 2015 12:52:51 -0400

> section, right? That is all I am suggesting - are there some other rules you

Just because a field value has been deprecated (obsoleted or made
historic) does not mean they are still not in use.  You cannot simply
write a field value in an RFC and expect to get that value assigned to
your spec.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 17:12:20 +0000

Hi Brian,

> Sent: Monday, April 27, 2015 9:53 AM
> To: [email-masked]

In this case, the field value would only be interpreted within the context of
an official UDP port number that specifies its use. The former holder of that
field value (RFC1475) would be explicitly deemed not applicable for this use.

Thanks - Fred