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

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 08 May 2002 16:12:27 -0700

hi Brian,

sorry for the late reply. from 2462 Section 5.3

    A link-local address is formed by prepending the well-known link-
    local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the
    interface identifier. If the interface identifier has a length of N
    bits, the interface identifier replaces the right-most N zero bits of
    the link-local prefix.  If the interface identifier is more than 118
    bits in length, autoconfiguration fails and manual configuration is
    required. Note that interface identifiers will typically be 64-bits
    long and based on EUI-64 identifiers as described in [ADDR-ARCH].

since the home agent knows the prefix length of the home link and
thereby the interface id length of the MN's HoA, it can construct
the link local address for the MN.

if the mobile node knows that it uses a different interface id for
the link local address and the home address, it should always set
the 'S' bit to 1. Then the home agent would defend only the home
address.

regards
Vijay

Brian Haley wrote:

> Hi Charlie and Vijay,
> 
> On April 23rd I raised an issue about the S-bit in Binding Updates on
> the mailing list that had only one response (Francis Dupont), hardly
> consensus.  Jari put it on the issues list for the draft, but wanted me to
> get more input on it.  Instead of re-posting to the list, I figured I'd
> send mail to you two since Charlie's the co-author and I've talked to
> Vijay about other draft things.
> 
> If you want to post a reponse to the list, that's fine, I just wanted to
> make sure other people hadn't missed it.  Francis had the same
> conclusion I did btw...
> 
> Thanks,
> 
> -Brian
> 
> 
> ------------------------------------------------------------------------
> 
> 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
> To:
> 
> mobile ip <[email-masked]>
> 
> 
> 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: Brian Haley <[email-masked]>
Date: Fri, 10 May 2002 17:14:51 -0400

Hi Vijay,

RFC 2462 (address autoconfiguration) tells you how to make a link-local
address from an interface identifier, but not how to make an address
identifier from a unicast address.  I guess the Home Agent could figure
this out since it should know the link type, but this will not work in all
cases (Section 2.5.4 of the new address architecture imposed some
limitations).

Anyways, maybe it is more useful to have the Mobile Node supply it's
interface identifier if it wishes to have more than one address registered,
then it's not ambigous.  I didn't really want to go there, I would still
favor removing the S-bit, that way the MN can register only the addresses
it wants.  Right now, if the S-bit isn't set, there is no way for the MN to
know exactly which addresses the HA configured - by the time it does
a prefix solicitation there could have been a change.

-Brian

P.S. I might be slow to respond to email next week...

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 May 2002 14:35:44 +0200

RFC 2462 (address autoconfiguration) tells you how to make a link-local
   address from an interface identifier, but not how to make an address
   identifier from a unicast address.

=> I don't know what is an address identifier. If it means interface
identifier then it is part of the unicast address and a known part
if the unicast address is a global address not starting with 000.

   I guess the Home Agent could figure
   this out since it should know the link type, but this will not work in all
   cases (Section 2.5.4 of the new address architecture imposed some
   limitations).
   
=> I disagree : this is easy in all reasonnable cases.

=> I don't like "subnet registrations" but this is not the good argument.

Regards

[email-masked]