RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt

["Tsirtsis, George" <tsirtsis at qualcomm.com>]

Hi Sri, Thanks for you comments. Please see comments inline...

-----Original Message-----
From: Sri Gundavelli [mailto:sgundave at cisco.com] 
Sent: Friday, August 10, 2007 6:25 AM
To: McCann Peter-A001034
Cc: mip4 at ietf.org
Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt 


I've reviewed this document. It is in a good shape. Few
comments on the final version. May want to add some
clarifying text.

Sri


---------------------------------------------------------
Section 2.3 Implicit and Explicit Modes



   "In this mode of operation all traffic to and from
    the IPv6 prefixes MUST be encapsulated over the IPv4 tunnel between
    the mobile node's IPv4 home address and the IPv4 address of the home
    agent, and as such it is transparent to any foreign agent in the
    path."


The above text is not clear on what the supported encap modes are. The
text seems to say the encap mode is I(b) or II(b). Should allow I(a) and

II(a) ?
If transparency to FA is desired for IPv6 traffic in implicit mode, I(b)
must be enforced. But, in CCOA mode, I(b) is an overhead.


GT> Sri, I(b) and II(b), keep things simple. To allow for I(a) we must
be confident that the HA can distinguish between CoA and CCoA
registrations in all cases. Are we sure HA implementations can always do
that? In other words, in the absence of an FA-HA authenticator is it
always possible for an HA to know whether a RRQ is coming from the MN or
the FA?


I). FA-COA Mode:

    HA========FA-----MN


Encapsulation modes for IPv6 traffic:

    a.) HA-FACOA{IPv6-Pak}

    b.) HA-FACOA{HA-MNHoA{IPv6-Pak}}




II). MN-COA Mode:

    HA================MN


Encapsulation modes for IPv6 traffic:

    a.) HA-MNCOA{IPv6-Pak}

    b.) HA-MNCOA{HA-MNHOA{IPv6-PAK}}


As well for the explicit mode, the document talks about "tunneling
to HoA or CoA". But, its not implicit, if this introduces a new
encap modes I(b) or II(b). Because, 3344, uses this style of
delivery for broadcast or multicast packets. Few more lines of
text will help.


GT> I am not sure what you call "a new encap mode"? what kind of
clarification would you think is necessary for I(b) and II(b)? I would
appreciate it if you could provide proposed text.

===================================================

Section 3.2 IPv6 Code Extension

> A new skippable extension to the Mobile IPv4 header


Should this be a non-skippable extension ? Its a reply and
MN cant ignore this. It is present, because MN asked for it
and it understands the format. Is it for supporting older
FA's in path and when the packets are tunneled to HoA ?

GT> I see your point but I think the extension works as skippable too.
The defined behavior for the mobile not receiving this extension is to
assume encapsulation of IPv6 over the HA-HoA tunnel, which is not
harmful (just less efficient). Its existence allows for encapsulation to
the MN's CoA but one can always encapsulate on the HA-HoA tunnel. Also
by keeping it skippable we save on code space (i.e., use of one
skippable code for all DSMIP extensions) which I assume is somewhat
limited? 

====================================================

Section 3.2  Code Values


> 10 registration rejected, not home subnet

> 11 registration rejected, Duplicate Address Detection failed

Some of these code values require some explanation. Some are
relevant only when the requested address is a prefix and some
when the address is a IPv6-HoA. Its not specified where exactly
each error code can be used. I understand, it may be implicit,
but, few lines will help.


GT> Maybe you missed it but use of these codes is I think well defined
in the Home Consideration section 4.3 paragraph 3 and 4. Could you take
another look and let me know if it is sufficient?

========================================================
Section 4.3

"If the IPv6 home address included in a IPv6 prefix request extension"

You mean "IPv6 prefix extension" ?. Its in other places as well...

GT> Ah yes, thanks. It in 6 places, I will correct it.

=========================================================
Section 4.3.1.  IPv6 Packet Processing

Should be mentioned that Proxy ND is required only when the requested
IPv6 address is a HoA and not a IPv6 prefix.

GT> Hmmm, yes maybe. Is that simple statement sufficient or should we
say anything more?


=========================================================

Section 4.3.2:

    "Even if the tunnel for IPv4 traffic terminates at a different point
    than the tunnel for IPv6 traffic (mobile node's CoA vs HoA), both
    tunnels MUST use the tunneling mechanism negotiated by the Mobile IP
    header as defined in MIPv4 [RFC3344].  When IPinIP encapsulation is
    negotiated IPv6 is tunneled over IPv4 according to [RFC4213].  GRE
    and Minimal Encapsulation techniques also allow tunneling of IPv6
    packet by setting the Protocol Type [RFC1701] and Protocol [RFC2004]
    fields to appropriate payload type defined for IPv6 by IANA."


When the packets are tunneled to the HoA, the inner capsulation
should be just IPv6-over-IPv4. I wonder, what is the value of using
GRE for the inner packets ? This alligns better with the delivery
style for broadcast and multicast packets, IMO.

GT> Yes you are right. Should I then say that when IPv6 is encapsulated
over the HA-HoA tunnel, RFC4213 should always be used? How is the
following?:

"When IPv6 traffic is encapsulated over the tunnel between the HA and
the mobile node's care-off address, the tunneling mechanism used should
be the same with the mechanism negotiated by the Mobile IP header as
defined in MIPv4 [RFC3344]. In that case, when IPinIP encapsulation is
negotiated, IPv6 is tunneled over IPv4 according to [RFC4213]. GRE and
Minimal Encapsulation techniques also allow tunneling of IPv6 packet by
setting the Protocol Type [RFC1701] and Protocol [RFC2004] fields to
appropriate payload type defined for IPv6 by IANA. When, however, IPv6
traffic is encapsulated over the tunnel between the HA and the mobile
node's home address, IPv6 is always tunneled over IPv4 according to
[RFC4213], no matter what tunneling mechanism is negotiated in MIPv4
signaling. "

============================================================
Section 4.3.2

" Packets addressed to the mobile node's IPv6 link-local address MUST
    NOT be tunneled to the mobile node.  Instead, these packets MUST be
    discarded and the home agent SHOULD return an ICMPv6 Destination
    Unreachable, Code 3, message to the packet's Source Address (unless
    this Source Address is a multicast address)."

The HA will probably never know the link-local address of the
mobile node ? The document does not specify the operation of the
mobile node using a IPv6 HoA on its home interface and also
there is no "Link-Local Address Compatibility (L)" flag to tell the
HA that the identifier for IPv6-HoA and the Link-local address is
the same.

GT> Actually I am strangling to remember why or when we wrote this.
Should I just remove it or is there something else we should say?

==============================================================

"IPv6 packets received from the mobile client"

It should be "mobile node". Some places the MN is referred to as
mobile client. This should be consistent with 3344 terminology.

GT> ok, thanks.

==============================================================
Section 4.8: Registration with a private CoA


You probably need a new type value for carrrying IPv6 packets in
UDP. MIP Tunnel Data Message [3519, Section 3.3]. Or just mention
that the IPv6 protocol number should be set when carrying IPv6
packets.

GT> OK, good point. So would the following text work?:

" 4.8.  Registration with a private CoA

If the care-of address is a private address then Mobile IP NAT Traversal
as [RFC3519] MAY be used in combination with the extensions described in
this specification. In that case the next header field of the Mobile
Tunnel Data message header [RFC3519] MUST be set to the value for IPv6."

===============================================================

Thanks
George

Tsirtsis, George wrote:
> Hi Peter,
>
> Kent sent me his comments offline and I have incorporated them in the
> draft. His main comment was about clarifying that implicit mode is
> entirely transparent to the FA, which I did.
>
> He is now, I think, on vacation so I could not check the changes with
> him. In any case I am sure he will check the document next week when
> he will be back.
>
> Regards
> George
>
>
> -----Original Message-----
> From: McCann Peter-A001034 [mailto:pete.mccann at motorola.com]
> Sent: Tuesday, August 07, 2007 3:52 PM
> To: mip4 at ietf.org; kleung at cisco.com
> Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt
>
> Thanks George for submitting the updated version.
>
> Kent, you said during the meeting that you had some comments on this
> draft.  Could you send them to the list, so that we can move ahead
> with this document?
>
> Thanks,
>
> -Pete
>
> Internet-Drafts at ietf.org wrote:
>> 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		: Dual Stack Mobile IPv4
>> 	Author(s)	: G. Tsirtsis, et al.
>> 	Filename	: draft-ietf-mip4-dsmipv4-03.txt
>> 	Pages		: 25
>> 	Date		: 2007-8-7
>>
>> This specification provides IPv6 extensions to the Mobile IPv4
>>    protocol.  The extensions allow a dual stack node to use IPv4 and
>>    IPv6 home addresses as well as to move between IPv4 and dual
>> stack    network infrastructures.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-03.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> i-d-announce-request at ietf.org 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-dsmipv4-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:
>> 	mailserv at ietf.org.
>> In the body type:
>> 	"FILE /internet-drafts/draft-ietf-mip4-dsmipv4-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: Mip4 at ietf.org
    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/


--
Mip4 mailing list: Mip4 at ietf.org
    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/