Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-ipv6-20.txt

From: [email-masked]
Date: Wed, 22 Jan 2003 07:51:12 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

	Title		: Mobility Support in IPv6
	Author(s)	: D. Johnson, C. Perkins, J. Arkko
	Filename	: draft-ietf-mobileip-ipv6-20.txt
	Pages		: 168
	Date		: 2003-1-21
	
This document specifies the operation of the IPv6 Internet with
mobile computers.  Each mobile node is always identified by its home
address, regardless of its current point of attachment to the
Internet.  While situated away from its home, a mobile node is also
associated with a care-of address, which provides information about
the mobile node's current location.  IPv6 packets addressed to a
mobile node's home address are transparently routed to its care-of
address.  The protocol enables IPv6 nodes to cache the binding of a
mobile node's home address with its care-of address, and to then send
any packets destined for the mobile node directly to it at this
care-of address.  To support this operation, Mobile IPv6 defines a
new IPv6 protocol and a new destination option.  All IPv6 nodes,
whether mobile or stationary can communicate with mobile nodes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-20.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-mobileip-ipv6-20.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

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mobileip-ipv6-20.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Bryan Wang" <[email-masked]>
Date: Wed, 22 Jan 2003 11:41:08 -0800

Hi folks,

I noticed draft 20 gives no alignment requirement for Binding Authorization
Data in section. 6.2.7  " The Binding Authorization Data option does not
have any alignment".

I guess one reason for giving no alignment to this option could be the
assumption that all the data members are bytes, since normally the 96 bits
auth data will be declared as 12 bytes, but what if an implementation want
to use an algorithm that handle it as 3 integers? that'll require an
alignment of 4n.

Further more, all MH headers MUST have length of 8n (6.1.1), and BAD MUST
always be the last option if presented(6.2), this actually forces BAD to be
always placed at the last 8n+2.

Therefore, I would suggest 8n+2 to avoid confusion and possible
implementations with misalignment.

Thanks,
Bryan Wang
Elmic Systems, USA
http://www.elmic.com

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 22 Jan 2003 14:01:50 -0800

> to use an algorithm that handle it as 3 integers? that'll require an

it is natural to treat the auth data as 12 bytes. so there is no
alignment requirement for the BAD option.

> implementations with misalignment.

hmmm.. I was one who suggested removing the alignment requirement
for the BAD option. its the MH header which has the alignment 
requirement of 8n. not the BAD option. 

but you are right. you still have to introduce two bytes of 
padding before the BAD option to satisfy the two conditions
1. MH header MUST have length of 8n.
2. BAD MUST be the last one.

but I am not sure if we should specify alignment requirements for 
the BAD option just to satisfy the above two conditions. what do 
others think?

I am also fine with putting back the alignment requirement if 
needed.

Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 23 Jan 2003 10:04:45 -0500

Vijay

Sounds like a 1 byte allignment for the BAD option, so the spec
should specify an n+2 allignment.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07