Subject: [Mip6] FW: [mipv6_support:00292] problem with Mobile IPv6 mobile node TAHI test suite

From: "Ed Remmell" <[email-masked]>
Date: Fri, 12 Dec 2003 15:39:50 -0800

FYI -

We try to run the TAHI MIPv6 MN test against our MN implementation, and
we get a bunch of test failures, mainly because our embedded systems
implementation of "MN return to home" is somewhat different from what is
specified in the MIPv6 draft (we always register with the HA specifying
L=0, so then when we return home we can do standard IPv6 Address
Resolution rather than the DAD hack to resolve the HA's MAC address, the
source address of the NS we send is our auto-configured link-local scope
address). See the email below. The attachment referred to by that email
is:

http://users.piuha.net/jarkko/publications/mipv6/issues/issue248.txt

So, what is supposedly "perfectly acceptable behavior for <our> embedded
systems implementation" of setting L=0 in every home registration BU is
resulting in TAHI conformance test failures. Since we are successful at
many other TAHI test suites and IPv6 Ready logo certification, this
isn't a big concern for us currently. But, it may be interesting for
you'all to see how some of these MIPv6 legacy requirements that have
hung around in the MIPv6 draft can have an effect. If you have any
helpful opinions/information about this that could add weight to our
position about these (L) bit requirements (i.e. "change your MN
implementation" is not helpful ;-), please email them to
[email-masked] referencing mipv6_support:00292 (and please copy
me).

I can email a tcpdump-format packet capture of our MN return-to-home
behavior, if you are interested.

Thanks.
- Ed Remmell
Elmic Systems

-----Original Message-----
From: Ed Remmell [mailto:[email-masked]] 
Sent: Friday, December 12, 2003 3:18 PM
To: 'Shouichi Watanabe'
Cc: [email-masked]; 'Yamasaki-san'; 'Matsuura-san';
[email-masked]
Subject: RE: [mipv6_support:00292] problem with Mobile IPv6 mobile node
TAHI test suite

Watanabe-san,

> In Draft, performing DAD to link-local address by being
> referred to as Home Reg BU(L=0) at the time of returnning 
> Home may not be restricted.
> 
> Refer to 11.7.1
> ------------------------------------------------------------
> 11.7.1. Sending Binding Updates to the Home Agent
> (snip)
> To register a care-of address or to extend the lifetime of an
> existing registration, the mobile node sends a packet to its 
> home agent containing a Binding Update, with the packet 
> constructed as follows:
> 
> (snip)
>     o If the mobile node's link-local address has the same interface
>       identifier as the home address for which it is supplying a new
>       care-of address, then the mobile node SHOULD set the Link-Local
>       Address Compatibility (L) bit.
> 
> ------------------------------------------------------------
> Has your implementation satisfied this?

No, we have intentially not satisfied this specific "requirement".

We think this is a useless requirement that was left in the MIPv6 draft.
Please reconsider the validity of the above "requirement" based on the
following (also, see the attached MIPv6 WG mailing list thread):

1) (S) bit was removed from MIPv6 draft, (L) bit is now obsolete:

We have been actively involved in the MIPv6 working group since draft
18+. The (L) bit was originally intended to be used with the (S) bit to
enable the HA to derive all of the other MN's home addresses from the
interface ID of a single MN home address (so that the MN only has to
register a single home address to register the entire set derived from
the specified IID), however the (S) bit was removed from the BU in a
previous draft so the (L) bit has become a useless relic.

2) "DAD versus DIID"

The IPv6 WG has discussed the topic of "DAD versus DIID", specifically
is DAD necessary for addresses that are auto-configured from a globally
unique (EUI-64) interface ID? The general consensus is that DAD is not
needed in this case.

It is significant that Microsoft (Greg O'Shea) agreed with me (see
attached) that the (L) bit should be removed. It is also significant
that Vijay Devarapalli, one of the MIPv6 working group members
affiliated with Nokia who has been very involved with Jari Arkko w/
regards to approving/controlling changes to the MIPv6 draft, states in
response to me (see attached) that "<it is> perfectly acceptable for
your embedded systems implementation <to always set L=0 in the BU>."
But, then this was late in the draft process, and it was very difficult
to make significant changes to the MIPv6 draft at this point.

Please consider modifying the TAHI MIPv6 test suite to not fail MIPv6 MN
implementations that do not implement this specific "requirement".

According to the attached, Jari Arkko says that they kept the (L) bit
requirements in the MIPv6 draft "because of the possibility of nodes who
optimize DAD by checking just the link-local address. The L bit allows
us to avoid this case." However, in my opinion these (L) bit
requirements are useless and perhaps even somewhat broken.

In the case of a IID that was not randomly generated per RFC-3041 but
instead is based on a globally unique EUI-64 (i.e. Ethernet MAC
address), there is very little chance of duplicate IID assignment,
except in the case of an administrative configuration error which will
result in more serious problems (for example, manually configuring two
Ethernet adapters on the same link to have the same Ethernet MAC
address). Per the "DAD versus DIID" discussion in the IPv6 WG, it
doesn't seem useful to perform DAD for this type of globally unique
(EUI-64) IID. So, then the "requirement" above is useless.

Note that in the case of home addresses generated from RFC-3041 IIDs,
the MIPv6 draft says:
"   o  If the home address was generated using RFC 3041 [18], then the
      link local address is unlikely to have a compatible interface
      identifier.  In this case, the mobile node MUST clear the
      Link-Local Address Compatibility (L) bit."

This other (L) bit requirement I believe is broken. Consider the
scenario where a random RFC-3041 IID is set on the interface, and then
the same IID is used to auto-configure the link-local scope address as
well as the MN home address in this case. Since there is a (small)
chance of assigning a duplicate IID when using a randomly generated (and
not globally unique) RFC-3041 IID, it could be useful to have the HA
proxy for the derived auto-configured link-local scope address in this
case (L=1) to defend the home address against nodes on the home link
that optimize DAD, however the draft requires the opposite MN behavior
L=0. This is because originally the (L) bit was intended to be used with
the (S) bit, that's mainly why these "requirements" say what they do.

<snip>

Perhaps you can restructure the TAHI tests so that if a vendor (i.e.
Elmic) doesn't implement "MN return to home" functionality exactly as
you expect, it won't cause them to fail a large number of tests for this
reason. Right now, I believe a number of the MIPv6 MN TAHI tests cover
the same "MN return to home" scenario, and then we would fail each of
those TAHI tests for the same reasons.

Thanks.
- Ed Remmell
Elmic Systems

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6