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

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

inline

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

 

> -----Original Message-----
> From: Hesham Soliman [mailto:Hesham at elevatemobile.com] 
> Sent: Friday, August 10, 2007 5:44 AM
> To: 'Tsirtsis, George'; 'Sri Gundavelli'; 'McCann Peter-A001034'
> Cc: mip4 at ietf.org
> Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt 
> 
> 
>  > =========================================================
>  > 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?
> 
> => Basically we need to say that the HA will defed the IPv6 address by
> sending a proxy Neighbour Advertisement message. RFC 3775 talks about
> resending the message once for reliability. You could  refer to that
> behaviour. 
> 

I meant for the case, when the MN requests a prefix. HA need not
do any IPv6 ND operations. A simple route for the prefix over the
tunnel should be sufficient.

GT> Yes, I agree. I am going to edit the text in section 4.3. as
follows:
" When the IPv6 prefix extension contains a /128 IPv6 address
and unless this home agent already has a binding for the
given IPv6 address indicated, the home agent MUST perform
Duplicate Address Detection <xref target="RFC2462"/> on the
mobile node's home IPv6 link before returning a registration
reply. This ensures that no other node on the home link is
using the IPv6 home address. Duplicate address detection is
not required when the IPv6 prefix extension contains a
prefix."


>  > 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?
> 
> => I can't remember why we wrote this either. Looks like a 
> bug, but I'm
> wondering whether we should have the L-flag equivalent here 
> at all. It'd be
> interesting to see if anyone cares about link-local traffic, 
> e.g. DHCPv6,
> MLD...etc. 
>

The draft did not talk about of the use of IPv6 home address on the
home link. If the MN is on a virtual link or never at home, there
is no need for the HA to defend the mobile node's link-local address.
But, there is no such assumption mentioned in the spec. If the mobile
node operates as a normal MIPv6 node on the home link, we need to make
sure that address is defended by the HA, else it might loose it. MN
might use a link-local source address for DHCPv6 requests.

GT> I guess the fundamental question is whether the case of MN "at home"
is of interest to the group. I do not see a strong need for this since
MIPv4 in the field is typically deployed in "virtual link" mode. If
people feel strongly about support for home link operation we have to
add some more language around that, otherwise I will just state that
this is not supported at this point.

 Thoughts?
George


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