Subject: [nemo] issue 93 summary

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 7 Jun 2007 12:54:07 +1000

In light of the discussions that went on I thought it would be useful to
summarise the issue and discussions so far to give people who haven't kept
up an insight into what this is all about. 

First the issue text discussed the need for a "TLV" type encoding between
the outer IP header and the inner UDP header. The reason specified in the
issue was that the upper layer parsing the packet can't tell what
information follows UDP unless it is explicitly encoded. Upon further
discussion it was clear that this rationale is not true because the upper
layer can always parse the version field in the IP header following UDP. 

However, the following question was "what if the information following UDP
was not an IP header?". One could encode messages (at least in theory) that
follow UDP and that are not IP. But to save space and reading time, the main
(probably only) example for such information is the use of GRE
encapsulation. Some people don't see the need for the use of GRE and some
people do. I suggested that GRE can be used before UDP and not after, but
that was seen as unhelpful for cases where a NAT is present. 

Since I, after substantial effort, still couldn't find out what the
deployment scenario that needs this might be, I won't try to invent a
scenario for GRE on behalf of people who are calling for it and I'll leave
the floor open for that discussion. The point I wanted to highlight here
that practically this is the only reason left for adding TLV encoding. 

Finally, there are 3 options available for us to move forward and I'll use
the same numbers that Raj use to avoid confusing people:

1. Do nothing, keep the draft as is. 

2. Specify a different port number for the different format suggested.

3. Add the TLV encoding suggested in the issue. 

1) above implies that should there be agreement in future that the format
suggested in this issue is necessary, it can be achieved using option 2
(i.e. specify a new port that carries that format). This can be used if, for
example, GRE is needed for NETLMM. A MAG can use a different port from the
one used by the MN. The main reasons expressed by people for choosing 1
were:
 a) Adding 4 bytes on every packet is not needed. 
 b) GRE is not needed. 

2) above is pretty clear to everyone I think but Karen Nielsen raised some
questions that people should read. 

3) I believe 3 is also clear for everyone. Going to 3 will not require a
move to 2) later. Of course this comes at the cost mentioned above. I
believe the main reason expressed by people for this option was "future
proof". 

So, hopefully this gives a summary of the discussion so far. I think there
are basically two ways of finding concensus:
1. Discuss the rationale a lot more to make either side move. For instance,
discuss the deployment scenarios that require GRE, what is "future proof",
why the extra 4 bytes are an issue for those who chose 1) ...etc
2. Due to current threads more people might express their opionions. 

I'm not too hopeful with 2) above because most of the people that are
actively involved have commented. Plus it would actually be nice to see 1)
being achieved once in a while! So let's try to do that. 

Hesham

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 7 Jun 2007 00:30:13 -0500

Hi all,

If I understand Jari comments correctly, I think at one point, he
mentioned that we need to revisit/revaluate the existing text in the
draft. I looked into the draft but the only thing that I found w.r.t
option (1) is the following text:

LOCATION NO. 1:
===============
2.3.2.1 Visited network supports IPv4 only (private addresses)

   In this scenario the mobile node will need to tunnel IPv6 packets
   containing the binding update to the home agent's IPv4 address. In
   order to traverse the NAT device, IPv6 packets are tunneled UDP and
   IPv4. The UDP port used to send the IPv6 packet is TBD.

Basically there is no text included in the draft to explain how to
identify the type of payload that is encapsulated in UDP. In other words
and strictly speaking, if we take the draft most relevant text above,
this "TBD" reserved UDP port will always indicate that the payload is an
IPv6! 

LOCATION NO. 2:
===============

Under section 8. IANA considerations:
"
8. IANA considerations

   The specification requires the following allocations from IANA:
   - A UDP port is needed for the NAT traversal mechanism described in
     section 4.1.
"

Well, looking under section 4.1, I found the following sentence which
suggest that an IPv4 packet may be encapsulated in UDP in IPv4.
"
.........
   All tunneled IPv4 packets will contain the mobile node's IPv4 home
   address in the source address field of the inner IPv4 packet and the
   correspondent node's IPv4 address in the destination address field.
   The outer IPv4 header is the same whether the inner packet is IPv4 or
   IPv6.
.....
"

The least that I may say about the existing text, it is inadequate. IMO,
it needs serious update to identify the mechanism needed by the
receiving node to identify the type of packet that is encapsulated in
UDP then in IPv4.

Finally, I still favor option 3 considering that the 4 bytes can be
compressed to much less than 4 bytes reducing the overhead on the
wireless link.

Regards,
Ahmad

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Wednesday, June 06, 2007 9:54 PM
> To: [email-masked]; [email-masked]
> Subject: [Mip6] issue 93 summary
> 
> 
> 
> In light of the discussions that went on I thought it would 
> be useful to summarise the issue and discussions so far to 
> give people who haven't kept up an insight into what this is 
> all about. 
> 
> First the issue text discussed the need for a "TLV" type 
> encoding between the outer IP header and the inner UDP 
> header. The reason specified in the issue was that the upper 
> layer parsing the packet can't tell what information follows 
> UDP unless it is explicitly encoded. Upon further discussion 
> it was clear that this rationale is not true because the 
> upper layer can always parse the version field in the IP 
> header following UDP. 
> 
> However, the following question was "what if the information 
> following UDP was not an IP header?". One could encode 
> messages (at least in theory) that follow UDP and that are 
> not IP. But to save space and reading time, the main 
> (probably only) example for such information is the use of 
> GRE encapsulation. Some people don't see the need for the use 
> of GRE and some people do. I suggested that GRE can be used 
> before UDP and not after, but that was seen as unhelpful for 
> cases where a NAT is present. 
> 
> Since I, after substantial effort, still couldn't find out 
> what the deployment scenario that needs this might be, I 
> won't try to invent a scenario for GRE on behalf of people 
> who are calling for it and I'll leave the floor open for that 
> discussion. The point I wanted to highlight here that 
> practically this is the only reason left for adding TLV encoding. 
> 
> Finally, there are 3 options available for us to move forward 
> and I'll use the same numbers that Raj use to avoid confusing people:
> 
> 1) above implies that should there be agreement in future 
> that the format suggested in this issue is necessary, it can 
> be achieved using option 2 (i.e. specify a new port that 
> carries that format). This can be used if, for example, GRE 
> is needed for NETLMM. A MAG can use a different port from the 
> 2) above is pretty clear to everyone I think but Karen 
> Nielsen raised some questions that people should read. 
> 
> 3) I believe 3 is also clear for everyone. Going to 3 will 
> not require a move to 2) later. Of course this comes at the 
> cost mentioned above. I believe the main reason expressed by 
> people for this option was "future proof". 
> 
> So, hopefully this gives a summary of the discussion so far. 
> I think there are basically two ways of finding concensus:
> 1. Discuss the rationale a lot more to make either side move. 
> For instance, discuss the deployment scenarios that require 
> GRE, what is "future proof", why the extra 4 bytes are an 
> issue for those who chose 1) ...etc 2. Due to current threads 
> more people might express their opionions. 
> 
> I'm not too hopeful with 2) above because most of the people 
> that are actively involved have commented. Plus it would 
> actually be nice to see 1) being achieved once in a while! So 
> let's try to do that. 
> 
> Hesham
> 
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 7 Jun 2007 17:03:01 +1000

> option (1) is the following text:

=> No that's not true at all. There is an IP version field in the IP header
that tells you what the header is. The fact that the IP header fields (for
v4 or v6) are not revisited in this draft does not in any shape or form
suggest that we have no way of parsing header. I suggest that we get off the
header parsing argument because frankly, it's a waste of time. Everyone
knows (including people who want option 3) that you can do this with the
version field. Let's not debate facts here, it's pointless. 

Hesham

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 7 Jun 2007 10:03:03 -0500

Thanks Hesham. Understood!

However, the comment was not regarding a technical issue (in the sense
right vs. wrong) here, but about adequacy of the text. It may ,very
well, be straight forward in your mind, however, we are not writing a
standard for the editor to read and understand! Right?

On the other hand, since we are addressing adequacy of the draft text,
let me point out a couple of places that you may need to fix in order to
reduce the reader's confusion.

CASE No. 1:
===========
Under section: 2.3.2.1 Visited network supports IPv4 only (private
addresses)

"

Here, it is clear that the MN needs to use UDP whenever using a Private
IPv4 address, i.e. a NAT is assumed. However, I assume that the MN
probably does not know if it is using a private IPv4 address or to be
more accurate, if there is a NAT in path or not.

Reading further down under the same section when it talks about what the
HA does after receiving a BU with IPv4 HAO, it reads the following:

"
   After accepting the binding update, the home agent MUST create a new
   binding cache entry for the mobile node's IPv6 home address. If an
   IPv4 home address option were included, the home agent MUST create
   another entry for that address. All entries MUST point to the mobile
   node's IPv4 care-of address included in the source address of the
   IPv6 packet and represented as an IPv4-mapped IPv6 address. In
   addition, the tunnel used MUST indicate UDP encapsulation for NAT
   traversal. ....
"

Here it is assumed that there is a NAT and HA marked the tunnel with UDP
encapsulation for NAT traversal. Right?
There is a lot of assumptions can go in the mind of the reader why this
is true, however, the straight forward one is we are talking about
private IP addresses anyway. Ok, let us move on.

"
   .......... Hence, all packets addressed to the mobile node's home
   address(es) (IPv4 or IPv6) will be encapsulated in UDP then
   encapsulated in an IPv4 header that includes the home agent's IPv4
   address in the source address field and the mobile node's IPv4 care-
   of address in the destination address field.
"

Please tell me, which scenario we are talking about now?!
If we assume that we are talking about private IP addresses, then How in
the world, the HA will be able to send packet destined to the MN IPv4
care-of address, which is a private address.

OK here is one needs to be adequately clarified. [1]

CASE No. 2:
===========
Let us continue reading under the same section, the same comments above
applies on how the HA sends the BA as per the text below:

"
...
   ............... The binding acknowledgement is encapsulated in UDP
   then IPv4 with the home agent's IPv4 address in the source address
   field and the mobile node's IPv4 care-of address in the destination
   field. The inner IPv6 packet will contain the home agent's IPv6
   address as a source address and the mobile node's IPv4 care-of
   address in the destination address field. The latter is represented
   as an IPv4-mapped IPv6 address.
"

Are we still talking about private IPv4 addresses in this scenario? I
assume yes, because that is the title of the section and what the
previous text indicates. Then the same comment above applies here and an
adequate clarification is needed. [2]

Finally the section ends the discussion as below, which gives the
impression that this whole section assumes that NAT is always in path
but does not talk how the MN would know that to start with.

"
   The mobile node needs to maintain the NAT bindings for its current
   IPv4 care-of address. This is done through sending the binding update
   regularly to the home agent.
"

May be it is a good idea to up front highlight the assumption that this
section is based on to eliminate a lot of confusion, what is the
assumption behind the text of this section? Is it:
1. The IPv4 is a private IP address and there is a NAT on path all the
time, or
2. The IPv4 address is a private but not necessary there is a NAT, or
3. There is a NAT regardless of the type of IPv4 address allocated to
the MN.

Case No. 3:
=========
Under section 4.1. NAT detection and traversal, it reads:

"
   NAT detection is done when the initial binding update message is sent
   from the mobile node to the home agent. When located in an IPv4-only
   foreign link, the mobile node sends the binding update message
   encapsulated in UDP and IPv4. The source address of the IPv6 packet
   is the mobile node's IPv4 care-of address represented in IPv4-mapped
   IPv6 format. The destination address is the IPv6 address of the home
   agent. The IPv4 header contains the IPv4 care-of address in the
   source address field and the IPv4 address of the home agent in the
   destination address field.
"

This is a clear assumption that the MN uses UDP encapsulation (for
sending BU) any time when it is located in an IPv4 only foreign network.
Which I assume is the intent here. Let us move on and continue to read
under the same section.

Now, the below text MAY give an impression that UDP encapsulation is
done only when HA detects NAT in the path. Correct?

"
   ......... If the two addresses match, no NAT device was in the path.
   Otherwise, a NAT device was in the path and the NAT detection option
   is included in the binding acknowledgement. The binding
   acknowledgement, and all future packets, are then encapsulated in UDP
   and IPv4. The source address in the IPv4 header is the IPv4 address
   of the home agent. The destination address is the IPv4 address
   received in the IPv4 header encapsulating the binding update (this
   address will be different from the IPv4 care-of address when a NAT is
   in the path).
"

May be another place that clarification is needed. [3]
However, here, the dst. IP address is specified correctly:)

Reading the below text, I would suggest that an example for, at least,
data packets UDP encapsulation like the one for BU and BA is very useful
and probably needed. It makes things much cleaner. Instead of just have
an indirect reference as in the below paragraph. [3+.5=3.5]

"
   If no NAT device was detected in the path between the mobile node and
   the home agent then IPv6 packets are tunneled in an IPv4 header,
   unless the home agent forces UDP encapsulation using the F flag. The
   content of the inner and outer headers are identical to the **** UDP
   encapsulation case.*** 
"

CASE NO. 4:
===========
   A. Binding update received by the home agent:

              IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                 UDP header
                   IPv6 header (src=V4CoA, dst=HAADDR)
                      DST-OPT
                          HAO (IPv6 home address)
                      Mobility header
                          BU [IPv4 HAO]

   Where V4ADDR is either the IPv4 care-of address or the address
   provided by the NAT device. V4COA is the IPv4 care-of address of the
   mobile node. HAO is the home address option and BU is the binding
   update, which MAY contain the IPv4 home address option.

I believe the definition of V4ADDR is very useful and SHOULD be global.
This can be used whenever the text addresses HA functionality where NAT
vs. NO NAT is not clearly identified. It eliminates confusion. [3.5 +
0.5=4]

CASE NO. 5:
===========
Under section: 4.3.1 Sending packets from a visited network.

"
   When the mobile node is located in an IPv4 only network, it will send
   IPv6 packets to its home agent according to the following format:

                IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                 [UDP header]
                   IPv6 header (src=V6HoA, dst=CN)
                    Upper layer protocols

   Where the UDP header is only used if a NAT were detected between the
   mobile node and the home agent, or if the home agent forced UDP
   encapsulation.
"

Now, the use of the V4ADDR in this context is wrong. We are talking
about the MN sending an IPv6 packet in an IPv4 only network. MN will
always set the src addr of the outer header to MN's IPv4 Care-of
Address. Right?

The above format would be perfect if we are talking about the HA
receiving an IPv6 packet that the MN sent from an IPv4 only network.
Right?

The same comment applies to the following case:

"
  Similarly, IPv4 packets are sent according to the following format:

                IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                 [UDP header]
                   IPv4 header (src=V4HoA, dst=V4CN)
                    Upper layer protocols
"

An adequate clarification is needed. [4+1=5]

SUGGESTION:
===========
Finally, probably this suggestion is a little too late in the game and
have been discussed earlier, but since the MN is roaming in an IPv4 only
foreign network, SHOULD not we make it optional to the MN to request
that only an IPv4 HoA to be allocated. This would save resources at the
HA.

Regards,
Ahmad

> Sent: Thursday, June 07, 2007 2:03 AM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]; [email-masked]
> Subject: RE: [Mip6] issue 93 summary
> 
> 
>  > If I understand Jari comments correctly, I think at one 
> point, he  > mentioned that we need to revisit/revaluate the 
> existing text in the  > draft. I looked into the draft but 
> the only thing that I found w.r.t  > option (1) is the following text:
>  >
>  > LOCATION NO. 1:
>  > ===============
>  > 2.3.2.1 Visited network supports IPv4 only (private addresses)  > 
>  > Basically there is no text included in the draft to 
> explain how to  > identify the type of payload that is 
> encapsulated in UDP. In  > other words  > and strictly 
> speaking, if we take the draft most relevant text above,  > 
> this "TBD" reserved UDP port will always indicate that the  > 
> payload is an  > IPv6! 
> 
> => No that's not true at all. There is an IP version field in 
> the IP header that tells you what the header is. The fact 
> that the IP header fields (for
> v4 or v6) are not revisited in this draft does not in any 
> shape or form suggest that we have no way of parsing header. 
> I suggest that we get off the header parsing argument because 
> frankly, it's a waste of time. Everyone knows (including 
> people who want option 3) that you can do this with the

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 07 Jun 2007 10:58:24 -0500

<Chair-hat-off>

In the context of DS-MIP6 and the scope or usage of this functionality by
MIP6 or NEMO, I do believe that option 1 is sufficient.

The type of packets encapsulated in the UDP tunnel are either IPv4 or IPv6.
And as the discussion has shown, parising of these packets is not really a
problem. There is no need for an explicit indication of the encapsulated
packet type via a header.

The 4 byte header as proposed by option 3 adds to the overhead since every
packet between the MN and HA will now include it. It could be argued that 4
byte overhead in the overall scope of the headers of the tunnelled packets
is not a significant percentage but it still is an overhead that can be
avoided. Additionally HC schemes that may be applied to the normal IP/UDP
headers will need to be updated or will have to consider this 4 byte header
as well. So I do not believe option 3 from an efficiency perspective is a
good choice for MIP6.

It has been mentioned (by Vijay) that we already support option 2 since we
have a separate port for the ESP encapsulated packets and we have this port
for packets tunnelled over UDP. If GRE or other packets are in the future
determined as being essential to be tunnelled over UDP between the MN and HA
another port could be reserved as well. I am of the opinion that when the
need for carrying GRE or other packet types is demonstrated either in the
MIP6 or NEMO WGs or elsewhere and there is agreement on it, a draft could be
written that updates the current DS-MIP6 document and proposes a new port
that would enable the MN and HA to process those packets. I do not believe
this is being short-sighted because the need for GRE in the context of MIP6
and NEMO has not really been proven inspite of the numerous discussions on
the ML. Having felxibility in a protocol is also not a good reason (kitchen
sink theory).

-Raj

</Chair-hat-off>

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 07 Jun 2007 10:58:25 -0500

Hello,

In order to get a better sense of consensus, I would encourage more people
who are on the MIP6 ML to express their opinion on this issue (summarized
below by Hesham). 

-Raj

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Jun 2007 12:02:30 +0300

Hesham,
> version field. Let's not debate facts here, it's pointless. 
He's not saying its impossible, he's saying it needs to be
documented. I agree with that requirement. You need
to change the draft no matter what (but of course
adding this description is trivial).

Jari

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 23 Jun 2007 00:14:44 +1000

> shape or form

=> Agreed. Ahmad said in a later email that it is more of an editorial
comment than a technical one. Depending on how we resolve this issue I'll
add this comment among several others that he sent. 

Hesham