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

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

Hi Sri, thanks...some more comments inline...

-----Original Message-----
From: Sri Gundavelli [mailto:sgundave at cisco.com] 
Sent: Monday, August 13, 2007 5:43 AM
To: Tsirtsis, George; 'McCann Peter-A001034'
Cc: mip4 at ietf.org
Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt 

Hi George,

Inline ... 

> -----Original Message-----
> From: Tsirtsis, George [mailto:tsirtsis at qualcomm.com] 
> Sent: Friday, August 10, 2007 3:21 AM
> To: Sri Gundavelli; McCann Peter-A001034
> Cc: mip4 at ietf.org
> Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt 
> 
> 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?
> 

Why will this be an issue just in implicit mode. If the "IPv6
Tunneling Mode Extension" is present, HA can send the IPv6 packets
in I(a)/II(a) mode i.e to a care-of address and not to the home
address. Now, if the CoA is FA-COA or a CCOA, will that be
important ? 

GT> It is actually important. The MN can only send the "IPv6
Tunneling Mode Extension" if it works in CCoA mode. See the following
quote from section 4.5:
"The mobile node SHOULD include exactly one IPv6 tunneling mode
   extension if it uses the co-located care-of address model and it
   wants to request that IPv6 packets are tunneled to its co-located
   care-of address.  If the mobile node uses the co-located care-of
   address model but it does not include the IPv6 tunneling mode
   extension the home agent will tunnel IPv6 traffic to the mobile
   client's home address.  The mobile node MUST NOT include an IPv6
   tunneling mode extension if it uses the care-of address mode of
   operation.  Note that if the mobile includes an IPv6 tunneling mode
   extension in this case, IPv6 packets could be tunneled to the FA by
   the HA.  The FA is then likely to drop them since it may not have
   appropriate state to process them."


HA simply wraps the IPv6 packets with the tunnel
header. If the packets are received at the FA, it simply forwards
them as in for the explicit mode. Also, the presence of "D" bit in
the RRQ, specifies if its FA-COA or a CCOA mode of operation. 

I'm ok either way. I was not sure, why in implicit mode, IPv6
packets cant be sent in I(a)/II(a) modes.


GT> The problem is that if the HA tunnels IPv6 packets to the FA and the
FA does not support IPv6, the packets will be dropped on the floor. In
implicit mode (i.e., the absence of an IPv6 tunneling Mode extension),
there is no way for the HA to know if the FA supports IPv6 or the
behaviors defined in this draft, so tunneling to the MN's IPv4 HoA is
always safer.

> 
> 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.
> 

Typical view of a MIP tunnel, is between FA-COA/CCOA to HAA and
there is just one tunnel. Tunneling to HoA introduces some what
a new tunnel i.e to the HA-MNCOA{HA-MNHOA{IPv6-PAK}}.
I was just saying, few more line of text might be good, that the
packet needs to be wrapped first in HAA-HoA and then HAA-COA 
wrappers. The text from 3344 on how broadcast/multicast packets
are sent, can be used here.

GT> OK, I see. I will modify the appropriate part of section 4.3.2 as
follows, based on corresponding text in 3344, so tell me if it works:
"   1) Registration request is received with one or more IPv6 prefix
   extensions.  An IPv6 tunneling mode extension is not included.

All IPv6 packets destined to the registered IPv6
prefix(es) MUST be tunneled by the home agent to
the registered IPv4 home address of the mobile.

===start of new text=======
The home agent first encapsulates the IPv6
packet addressed to the mobile node's IPv4 home
address, and then tunnels this encapsulated
datagram to the foreign agent. This extra level
of encapsulation is required so that IPv6
routing remains transparent to a foreign agent
that does not support IPv6. When received by the
foreign agent, the unicast encapsulated packet is
detunneled and delivered to the mobile node in
the same way as any other datagram. The mobile
node must decapsulate the received IPv4 packet
it receives in order to recover the original
IPv6 packet. 
======end of new text========
Additionally, the home agent MUST
be prepared to accept reverse tunneled packets
from the IPv4 home address of the mobile
encapsulating IPv6 packets sent by that mobile."

> ===================================================
> 
> 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? 
> 

Ok.

> ====================================================
> 
> 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?
> 

Ok.

> ========================================================
> 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?
> 
> 

Fine.

> =========================================================
> 
> 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. "
> 

This is fine.

> ============================================================
> 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."
> 

Ok.


Sri


--
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/