Subject: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt

From: [email-masked]
Date: Wed, 07 Feb 2007 15:50:02 -0500

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

	Title		: Mobile IPv4 Fast Handovers
	Author(s)	: R. Koodli, C. Perkins
	Filename	: draft-ietf-mip4-fmipv4-03.txt
	Pages		: 28
	Date		: 2007-2-7
	
This document adapts the Mobile IPv6 Fast Handovers [1] to
    improve delay and packet loss resulting from Mobile IPv4 handover
    operations.   Specifically, this document addresses movement
    detection, IP address configuration and location update latencies
    during a handover.   For reducing the IP address configuration 
    latency, the document proposes that the new Care-of Address is 
    always made to be the new access router's IP address.   Additional
    mechanisms may be defined in the future versions of this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-03.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-mip4-fmipv4-03.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-mip4-fmipv4-03.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.
-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 14 Feb 2007 11:02:38 -0500

Alex,

Does this new version address all of your comments?

Rajeev, I note that there are a number of nits found by
the idnits tool at 
http://tools.ietf.org/wg/mip4/draft-ietf-mip4-fmipv4/draft-ietf-mip4-fmi
pv4-03.nits.txt

Could you please take care of them?

Assuming Alex is ok and the nits are addressed, I will
go ahead with requesting publication.

-Pete

[email-masked] wrote:
> [email-masked] with the word unsubscribe in the body
> of the message.  
> logging in, type "cd internet-drafts" and then "get
> draft-ietf-mip4-fmipv4-03.txt".   
> 
> http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt  
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Feb 2007 20:39:37 +0100

> Does this new version address all of your comments?

Yes, it addresses most of the comments I've raised recently, thanks 
Rajeev.  Checksum copypaste is there.

There may be however some editorial consistency.  I've read it detail, 
checking for consistency of spec, not of protocol, and I believe there 
are some text consistency issues.  I went through the pain of reporting 
them all, but I realize that if some of them are addressed then new ones 
may arise, etc.  So I'm not sure how much should I insist on this.

For example I believe the document could benefit from its own 
Terminology section, easier for reader than to search for eg 'PAR' in 
the FMIPv6 RFC.

Then the reference to 802.11r isn't here either, and 802.11r 
specifically uses MAC messages that look very much like FMIP (discovery 
of neighborhood through beacons, etc).

Then are the following: reference [1][2], flags Codes and other contents 
decriptions, coherent address assignment, MAC address length, HI/HAck 
protection, etc.  See below.

Thanks for asking,

Alex

---------------------------------------------------------------------
> This document assumes that the reader is familiar with the basic 
> operation and terminology of Mobile IPv4 [1] and Fast Handovers for 
> Mobile IPv6 [1].

'[1]' is FMIPv6 and MIPv4 is none.  Suggest replace the first '[1]' with 
a '[2]'.  In several places throughout the document this should be made 
sure ok.

Still editorial: "protocol disengages" instead of "protocol disengage". 
  But these kinds could be caught by last stages of editing I believe.

Figure 1 "Predictive" pictures at bottom an FBU sent to NAR and then NAR
forwards it to PAR.  In a way it makes sense for "Predictive" but it
clashes with "Reactive" where the FBU is really sent to NAR IP address.
  Suggest FBU Predictive to NAR be not ">" but somehow ")".

> In any case, NAR MUST forward the contents of this message, starting
>  from the Type field, to PAR, which means the Source and Destination
>  IP addresses now contain the IP addresses of NAR and PAR 
> respectively.

Well, pure 'forwarding' doesn't modify any packet except for TTL.  The
above text seems to mistake 'forwarding' with creation of a new IP
header and copying the ICMP contents from the received packet to the
new.  Suggest eliminate use of 'forward' and use 'transmit'.  Or use the
terms 'rewrite addresses in IP headers'.

Or maybe I'm too picky on the term 'forwarding'... but should be clear
to reader that this is either a new packet or address rewriting.

> The protocol provides an option for NAR to return NCoA for use by the
>  mobile node.   When NAR can provide an NCoA for exclusive use of the
>  mobile node, the address is supplied in the HAck message.   The PAR
>  includes this NCoA in FBack.

Suggest add text to say that this method of address allocation has
strong implications on the use of DHCP or IPv4 Stateless Address
Auto-configuration.  If HAck-assigned addresses are used then DHCP and
SLAAC shouldn't be used, or similar.

> Sending FBU from the new link (i.e., reactive mode) is similar to 
> using the extension defined in [2].

Reference [2] is MIP4, should be [1] FMIPv6?

>    The FBU format is bitwise identical to the Registration Request
>     format in RFC 3344.

Use '[2]' instead of RFC3344?  Or '[RFC3344]'?  Or '[2] (RFC3344)'? 
Rather than writing only 'RFC 3344'.

FBU Flags:
> x|x|D|M|G|r|T|x
> Flags                  See RFC 3344

RFC3344 RegReq Flags:
> S|B|D|M|G|r|T|x
> S - simultaneous bindings
 > B - broadcast datagrams

Suggest text to say that FMIPv4 on AR ignores flags S and B and MN sets 
them both to '0'.

>       Home Address           MUST be PCoA (i.e., either co-located CoA or
>                               Home Address)

Suggest text 'MUST be PCoA, as a co-located CoA or as MN's Home 
Address', otherwise risk of reading 'Home Address MUST be Home Address'.

FBack contents:
>        Identification         a 64-bit number used for matching FBU. See
>                               RFC 3344.

Suggest text to say that the Id is copied from the FBU this is a reply 
to.  This text is already written in the HAck id to HI.

PrRtAdv contents:
>      Code             0, 1, 2, 3 or 4. See below.

Below are described only Codes 0 and 1.  But at least till the end of 
the section 5.4 there's no description of codes 2, 3 nor 4.  Suggest to 
describe the effects of using all codes (0-4) in this section.

Is this the same Codes in HAck (section 5.5.2)?  HAck codes make no 
sense in PrRtAdv.  What is it, sorry?

PrRtAdv contents:
>     New CoA Option
>                       MAY be present when PrRtAdv is sent
>                       unsolicited. PAR MAY compute new CoA using NAR's
>                       prefix information and the MN's L2 address, or by
>                       any other means.

Suggest text to say that in case the PrRtAdv option contains a new CoA 
to be assigned by the MN then this has strong impacts on the use of DHCP 
or SLAAC, in addition to the use of HAck-assigned addresses.

HI Contents:
>      New Care of Address
>                       The IP address the MN wishes to use when
>                       connected to the destination. When the `S' bit is
>                       set, NAR MAY assign this address.

Specify that if this field is present then the NCoA in HAck and in 
PrRtAdv contain the same thing, and that it has impacts on the use of 
DHCP and SLAAC.

Option formats:
>     Length           The length of the option (including the type and
>                         length fields) in units of octets.   For example,
>                         the length for IEEE 802 addresses is 1 [IPv6-
>                         ETHER].

'[IPv6-ETHER]' reference is undefined.  I don't know where it should point.

IEEE 802 MAC addresses are 6octet long (48bits).

Type+Len+MAC would make for 10 octets.

I'm not sure what was the authors' intention on how to encode this, but 
it's not clear.

Or maybe it was meant 'in units of 10 octets'?

>     6.2. New IPv4 Address Option Format
> 
>     This option is used to provide the new router's IPv4 address in
>     PrRtAdv.

... or the NCoA in PrRtAdv.

>      New IPv4 Address
>                         NAR's IPv4 address or the NCoA assigned by NAR.
                           ...or the NCoA...

>     7. Security Considerations
> 
>     The FBU and FBack messages MUST be protected

Suggest text to say that HI/HAck must be protected too.

> 8. IANA Considerations

Suggest text to say that Types, Sub-types and Codes are to be assigned 
supposedly from two different spaces: ICMP and Mobile IP.

Pete wrote:
> 
> Rajeev, I note that there are a number of nits found by the idnits 
> tool at 
> Assuming Alex is ok and the nits are addressed, I will go ahead with
>  requesting publication.
> 
> -Pete

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 14 Feb 2007 20:47:54 -0800

Hi Alex,

> may arise, etc.  So I'm not sure how much should I insist on this.

I agree that any editorial issues need to be addressed, and thanks for doing
the review. However, some may be more like "style" issues (e.g., the Figure
for predictive handover, which is borrowed from RFC4068), which are best
left alone at this stage. Also, RFC Editor will catch/suggest some changes
too. 

Also, our thinking has been that folks should use RFC4068 alongside this
document. Otherwise, we will be obliged to put large portions of that
document here. Although I agree that the document should be self-contained
as much as possible, we need to recognize the normative dependency both for
concepts and protocol dynamics.

I will look at the comments below and revise the document.

-Rajeev

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Feb 2007 10:07:36 +0100

> left alone at this stage. Also, RFC Editor will catch/suggest some changes

I agree the Figure remark can be considered style, to the extent that 
one can talk 'style' with a text file :-)  (use ')' arrows instead of 
'>' when forwarding through an entity).

I agree that some nits will be caught by RFC Editor and they'll surely 
suggest additional changes.

> concepts and protocol dynamics.

I think folks reading two RFCs instead of one is a burden.  If the two 
RFCs were dependent (implement rfc4068 in order to be able to implement 
this draft) then I agree with you.  But they seem very separate, one can 
easily implement FMIPv4 w/o FMIPv6 and vice-versa.

The dependency FMIPv4-FMIPv6 is much less than FMIPv4-MIPv4.

This discussion is about inserting or not a Terminology section in this 
draft, right?  I suggest to do it, for the reasons above.  What do the 
others think about this?

> I will look at the comments below and revise the document.

Thanks Rajeev,

Alex

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 15 Feb 2007 09:05:34 -0800

Okay, I will include the Terminology Section.

Thanks,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 23 Feb 2007 12:45:52 -0800

Hi Alex,

I have revised the draft again based on your input, which's been quite
useful. It should show up on the ML soon. I provide some replies on-line.

Thanks. I think I have addressed the issues. I would like to move forward.

Regards,

-Rajeev

> a '[2]'.  In several places throughout the document this should be made

The references should be okay now.

>   But these kinds could be caught by last stages of editing I believe.

Done.

> to reader that this is either a new packet or address rewriting.

Revised the text a bit to indicate that it's a new packet with src/dst
addresses set to NAR and PAR.

> SLAAC shouldn't be used, or similar.

Added text " Nevertheless, the MN should be prepared to use this address
instead of performing DHCP or similar operations to obtain an IPv4 address."

I think it is sufficient to get across the point that there are implications
to using DHCP.

> Rather than writing only 'RFC 3344'.

Done.

> Suggest text to say that FMIPv4 on AR ignores flags S and B and MN sets

Done.
> Address', otherwise risk of reading 'Home Address MUST be Home Address'.

Revised text.

> to.  This text is already written in the HAck id to HI.

Done.

> sense in PrRtAdv.  What is it, sorry?

Okay, the remaining codes are defined in rfc4068. But, I have provided them
here so that there is no need to go back to rfc4068. This also meant
providing the details of neighborhood discovery in Option-Code field in the
LLA format as in rfc4068. I think this has improved the readability and
harmonized the ID with rfc4068 for maximum compatibility.

> or SLAAC, in addition to the use of HAck-assigned addresses.

Added the text mentioned above.

> PrRtAdv contain the same thing, and that it has impacts on the use of

Same as above.

> Or maybe it was meant 'in units of 10 octets'?

Actually, the length is in 8 octets. So, with Type+Len+MAC, it would be 1.
However, the Option-Code field in the LLA would necessitate some padding.

> ... or the NCoA in PrRtAdv.

Done.

> Suggest text to say that HI/HAck must be protected too.

Revised text.

> supposedly from two different spaces: ICMP and Mobile IP.

Done.

Thanks again.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 23 Feb 2007 12:58:29 -0800

> useful. It should show up on the ML soon. I provide some replies on-line.

In the meanwhile, you can access it from

http://people.nokia.net/~rajeev/draft-ietf-mip4-fmipv4-04.txt

-Rajeev

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Feb 2007 15:25:03 +0100

Hi Rajeev, thanks for revising so quickly.

> I think it is sufficient to get across the point that there are implications

That's a good point.

> harmonized the ID with rfc4068 for maximum compatibility.

Thanks, I'll have to read that in detail.

> Actually, the length is in 8 octets.

Right.

> So, with Type+Len+MAC, it would be 1.

Right.

> However, the Option-Code field in the LLA would necessitate some padding.

That's why you removed the reference to IPv6-ETHER?  Or the talk about 
the 48bit MAC addresses?  Do we have a standard IPv4 means to pad?  I 
don't think.  We do in IPv6 but not in IPv4... no?

draft:
>    Depending on the size of the individual LLA option, appropriate
>    padding MUST be used to ensure that the entire option size is a
>    multiple of 8 octets.

Sorry, just wondering whether we have an appropriate means of padding in 
IPv4.  Or maybe we can say that the IPv6-style padding should be used.

Alex

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 26 Feb 2007 08:41:33 -0800

> don't think.  We do in IPv6 but not in IPv4... no?

Actually, the reference to IPv6-ETHER was from RFC2461.

> IPv4.  Or maybe we can say that the IPv6-style padding should be used.

I think we could use IPv6-style (more specifically, RFC2461 style [see LLA
definition]) padding.

-Rajeev

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Feb 2007 18:18:46 +0100

> I think we could use IPv6-style (more specifically, RFC2461 style [see LLA

Can we say that ^ in thid draft (explicitely rfc2461-style LLA padding), 
instead of simply 'appropriate' padding must be used?

Thanks,

Alex
PS: because rfc3344 Mobile IPv4 defines a 'one-byte padding extension'
     which is only one byte.  Should FMIPv4 use MIP4 7 one-byte paddings?
     Or rfc2461-style type-length paddings?  What do you think.

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 26 Feb 2007 10:52:56 -0800

> instead of simply 'appropriate' padding must be used?

Okay.

>      Or rfc2461-style type-length paddings?  What do you think.

Hmm.. I prefer 2461-style because we don't need to use 7 one-byte paddings.
But I am okay with the latter too. Let me know. I would like to resolve this
and get the draft forward. It's been long..

Thanks,

-Rajeev

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Feb 2007 21:30:21 +0100

> and get the draft forward. It's been long..

Sorry for being long.  I believe the draft is in much better shape now.

I'm ok with mentioning 2461-style instead of 1-byte 3344-style.

Alex

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 28 Feb 2007 11:05:44 -0800

> I'm ok with mentioning 2461-style instead of 1-byte 3344-style.

To be clear, there are no pad options in 2461.

So, I will write that the entire LLA option must be a multiple of 8 octets,
and the byte fields following the LLA must be initialized to zero by the
sender and ignored by the receiver.
I think this allows the implementations to choose whichever mechanism best
suits. Ok?

-Rajeev

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Feb 2007 21:09:02 +0100

> I think this allows the implementations to choose whichever mechanism best

Not sure this suits.  We actually do byte-level padding with this.  The 
init-0 ignore on receive is for bit-bound fields, not byte-bound.  We 
can't use padding when the field is 17bits for example.

I think 2460 says there are two types of padding, pad1 and padn, and we 
should say use padn with its Opt Data Len set to 5 and the 5 next bytes 
set to 0.

IMHO

Alex

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 28 Feb 2007 13:14:17 -0800

On 2/28/07 12:09 PM, "ext Alexandru Petrescu"
<[email-masked]> wrote:

> Allright. We can specify padN must be used. That would take away any
> ambiguity.
> 
> -Rajeev
> 
> 
> 
> IMHO
> 
> Alex
> 
>> >
>> > -Rajeev
>> >
>> >
>> >
>>> >> Alex
>>> >>
>> >
>> >
> 
>