RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
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.
===================================================
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 ?
====================================================
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.
========================================================
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...
=========================================================
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.
=========================================================
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.
============================================================
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.
==============================================================
"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.
==============================================================
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.
===============================================================
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/
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
