Subject: [mobile-ip] S-bit and building a link-local address

From: Brian Haley <[email-masked]>
Date: Tue, 23 Apr 2002 17:55:27 -0400

Hi,

I have an issue with the use of the S-bit in Binding Updates.

I'll start with a hard question:

Where can I find the spec/RFC that defines how to build a link-local address
from a global unicast address?

The BU only has the global address, and I think everyone's assuming /64 prefix
lengths, but according to the addressing architecture
(draft-ietf-ipngwg-addr-arch-v3-07.txt, soon to update RFC 2373), that's not
the case:

Section 2.5.4 on Global Unicast Addresses

  "All global unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in section 2.5.1.  Global unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field."

I've been struggling with this one for a while, but it doesn't seem like we
can just mask-off the upper 64 bits, stuff an FE80 in there, and call it a
link-local address.  This isn't even considering the IPv6-over-foo RFCs.

So if that question can't be answered, I feel the S-bit must be removed
from the draft, unless someone is willing to write-up the method in
question, but since building link-local addresses has media type
implications, I wasn't going to go there.

This also has ramifications with the D-bit since Section 9.1 of the
Mobile IPv6 spec says we must do DAD for the link-local address.

Am I missing something here?

-Brian

---

From: Francis Dupont <[email-masked]>
Date: Wed, 24 Apr 2002 12:24:40 +0200

=> nowhere, the S-bit stuff makes the nasty assumption that the same
interface ID is used for every addresses...

=> this is exactly the assumption and I share your bad opinion about it.

=> Many people want to keep it because it makes some cases easier/faster.
We (you and me) don't like it but one can answer we may not use it
so the only thing we can get is no SHOULD (including through bad
wording) for the S-bit in the document.

=> same assumption... and the conclusion is DAD for the link-local
is enough.

=> unfortunately nothing.

Regards

[email-masked]

PS: I have two reasons to prefer registration for only one address:
 - far simpler
 - the link-local address is available for de-registration when
   the mobile comes back to home.