Subject: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt

From: [email-masked]
Date: Mon, 25 Feb 2008 14:15:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title		: Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)
	Author(s)	: H. Soliman
	Filename	: draft-ietf-mext-nemo-v4traversal-01.txt
	Pages		: 31
	Date		: 2008-2-25
	
The current Mobile IPv6 and NEMO specifications support IPv6 only.
   This specification extends those standards to allow the registration
   of IPv4 addresses and prefixes, respectively, and the transport of
   both IPv4 and IPv6 packets over the tunnel to the home agent. This
   specification also allows the Mobile Node to roam over both IPv6 and
   IPv4, including the case where Network Address Translation is present
   on the path between the mobile node and its home agent.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-mext-nemo-v4traversal-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
MEXT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mext

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 26 Feb 2008 08:56:24 +0100

Hi,
A late comment on the TLV encapsulation:
I think the TLV-header UDP encapsulation could be used for IP Tunneling
Optimization. For this reason, I would like to keep the overhead as small as
possible. Do we really need the Reserved field?  
And is a length field of only one octet not a little bit to small?
Encapsulated payload could exceed 255 octets.
Teco.

> -----Oorspronkelijk bericht-----
> Van: [email-masked] [mailto:[email-masked]] Namens
> [email-masked]
> Verzonden: maandag 25 februari 2008 23:15
> Aan: [email-masked]
> CC: [email-masked]
> Onderwerp: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt
> 
> 
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 27 Feb 2008 10:11:16 +1000

> possible. Do we really need the Reserved field?  

=> Yes I think we need the 32-bit alignment. I'm not worried about 1 byte.

 > Encapsulated payload could exceed 255 octets.

=> Yes, good catch, it's a bug, it should be 2 bytes.

Hesham

 > > Onderwerp: [MEXT] I-D 
 > ACTION:draft-ietf-mext-nemo-v4traversal-01.txt
 > > 
 > > 
 > > 
 > > This draft is a work item of the Mobility EXTensions for 
 > IPv6 Working
 > > Group of the IETF.
 > > 
 > > You can also visit 
 > https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 26 Feb 2008 17:57:14 -0800 (PST)

Hesham,

We have the "P" flag to the BU/BA messages in Proxy Mobile IPv6. So,
this draft should reflect that. I just do not know why IANA is not
managing this bit space, we can easily make an error and two drafts
will endup with the same bit value. Vijay: One more example why this
needs to be under IANA administration. We were debating why there is
no registry for MIP4, MIP6 or DHCP protocol message flags.

Sri

-----------
3.1.3 The Binding Update Message extensions

    This specification extends the Binding Update message with two new
    flags. The flags are shown and described below.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Sequence #           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|H|L|K|M|R|F|T|  Reserved     |           Lifetime            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> P Flag after the R flag.

3.2.3 Extensions to the Binding Acknowledgement message

    This specification extends the binding acknowledgement message with a
    new flag. The new flag is shown and described below.

                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                        |    Status     |K|R|T| Reserved|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           Sequence #          |           Lifetime            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> P Flag after the R flag.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 27 Feb 2008 10:06:42 +0100

>>>> TLV-header UDP encapsulation:
Are we sure we need the payload length field?
UDP length is already available, and this new length field is simply
UDP_Length - 12.

I do not prefer a mandatory 32-bit alignment carrying only a single octet
type field.
What about type dependent padding?

For types with 32-bit alignment:

       0                   1                   2                   3
      |     Type      |                   Reserved                    |

For types with low overhead:
       
       0 1 2 3 4 5 6 7 
      +-+-+-+-+-+-+-+-+
      |     Type      |
      +-+-+-+-+-+-+-+-+

Teco.

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 27 Feb 2008 22:59:13 +1000

Personally, I *strongly* prefer not to touch this. I would have preferred
not to have this silly TLV in the first place but to put it in context (this
is my personal opionion of course) this field will not be used by MN. The
reason IMO for having this was NETLMM people wanting to encapsulate things
like GRE... For those cases saving 3 bytes is not really worth it. 

Hesham 

 > -----Original Message-----
 > From: Teco Boot [mailto:[email-masked]] 
 > Sent: Wednesday, February 27, 2008 7:07 PM
 > To: 'Hesham Soliman'
 > Cc: [email-masked]
 > Subject: RE: [MEXT] I-D 
 >       |     Type      |                   Reserved           
 >          |

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 27 Feb 2008 23:03:17 +1000

ok thanks.

Hesham 

 > From: Sri Gundavelli [mailto:[email-masked]] 
 > Sent: Wednesday, February 27, 2008 11:57 AM
 > To: Hesham Soliman
 > Cc: [email-masked]
 > Subject: Re: [MEXT] I-D 
 >                                        |          Sequence # 
 >         |           Sequence #          |           Lifetime

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 27 Feb 2008 17:15:25 +0100

Hi Hesham,

I understand your opinion on alignment.

But: I think DSMIP6 provides the basics for what we could use for compressed
payload transport. Then, I prefer the one octet type header. But at that
time, there would be a limitation by the current specification.

Agreed that the length field is redundant?
Agreed the payload is not 32-bit aligned?

Regards, Teco
 
> Van: Hesham Soliman [mailto:[email-masked]]
> Verzonden: woensdag 27 februari 2008 13:59
> Aan: 'Teco Boot'
> CC: [email-masked]
> Onderwerp: RE: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-
> 01.txt
>

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 29 Feb 2008 12:44:29 +0900

Hello,

I have another question related to the TLV use. Since BU are supposed to 
always be sent in vanilla UDP encapsulation (this is a MUST in the 
draft) we are likely to receive both TLV-encapsulated and 
vanilla-encapsulated packets on the same port, right?

Therefore my question is: how the receiver is supposed to guess how to 
decapsulate the packet? Does it rely on the first bytes following the 
UDP header, to recognize IP or IPv6 packet? In this case we don't need 
the TLV or TV at all, do we?

Thank you for any answer on this... (even telling that my question makes 
no sense if I missed something, thanks!)

Best regards,
Sebastien

-- 
Sebastien Decugis
http://www.nautilus6.org