Subject: Re: [MOBILE-IP] Appendix

From: "Powell, Ken" <[email-masked]>
Date: Fri, 10 Nov 2000 17:25:18 -0500

Charlie,

I must have miscommunicated something here. The
text you proposed for appendix A has elements of
two conflicting approaches to solve the problem
of needing a global home address to generate a
global home address:

  A) The initial text for generating a temporary home
     address is only needed if we use the current
     technique of exchanging the router solicits
     and router advertisements.

  B) Steps 5 and 6 show how to send router solicitations
     and router advertisements using tunnels in a way
     that does not need the initial home address.

If we do B, we don't need to do A.

I have some big problems with B still. It was just
a quick proposal to give a vague idea how we could
meet Mattias's objectives. It does this by redefining
how router solicitations and router advertisements
are tunneled. This seriously impacts many sections
throughout the spec and needs to be fully defined
if we are going to use it.

Last night, I decided to run through the exercise of
finding the spec changes to support option B. I had a
gut feeling it was going to be difficult, and it
was. I'm including what I have so far with comments
sliced in showing the outstanding issues and giving
possible approaches to further changes. This is not
complete.

I think we should drop tunneling (option B) and return
to the original proposal for appendix A. I went back
to see how we stand with Mattias's key objectives by
doing this.

>> I would like the option to let the MN configure it's
>> home address as if it was at home, even if it is not
>> at home.

In approach A, the initial steps that generate a
temporary home address during the bootstrap phase
is the only part that is different. It does revert
to the same methods and results as if the mobile
node were physically at home once we get over the
bootstrap phase. The initial temporary address gets
deleted through the time-out mechanism if it does
not get updated through stateless address
autoconfiguration or DHCPv6.

>> What I want is to open up the possibility for the MN
>> to go through step 2-5 without neither having a home
>> address nor having been at home before.

The mobile node does not have to be preconfigured with
any global address. It just needs a globally unique
interface id.

>> Summary: we don't need a parallel address configuration
>> method for mobile nodes. A mobile node will be configured
>> exactly as if it was at home.

This is the piece we can't satisfy with option A, but can
with option B. Option A requires the additional address
configuration method to bootstrap communications.

Here are the detailed changes I came up with so far to
support option B. Side comments are bounded with "<>".
Are these changes really worth pursuing? Its going to
take much more effort to scrub it properly.

If we are going to adopt option B, we should do it now
because it is not backward compatible.

On page 70, replace the tunneling technique with:
=================================================

   In tunneling each such Router Advertisement to the mobile node, the
   home agent MUST construct the packet using IPv6 encapsulation [4] as
   follows:

    -  The tunnel entry point is the home agent's IP address to
       which the mobile node addressed its current home
       registration. If the router advertisement is being sent
       in response to a router solicitation from a node with no
       current home registration, the tunnel entry point is set
       to the exit point of the tunnel thru which the original
       router solicitation was received.

    -  The tunnel exit point is the primary care-of address. If the
       router advertisement is being sent in response to a router
       solicitation from a node with no current home registration,
       the tunnel exit point is set to the entry point of the tunnel
       thru which the original router solicitation was received.

       < I think its possible to do this, but I suspect it will
         require serious changes to existing stacks to carry the
         tunnel source and destination address up and down the
         stack with decapsulated packets. A possible way to avoid
         tunnel implementation issues is to support bindings
         on the home agent for the mobile node's link local
         address. Once done, the kernel could use much the
         same mechanisms to route RA/RS with link local addresses
         as it would use for routing the mobile node's global
         home addresses. This of course would require another
         whole series of changes to the spec. >

    -  The Source Address of the inner IPv6 header is set to the
       home agents link-local IP address on the home network.

    -  The Destination Address of the inner IPv6 header is set to
       the mobile node's home subnet link-local address.

       < I first intended to use the all-nodes multicast address,
         but didn't know if IPsec works well with multicast
         addresses. >

    -  The inner IPv6 header must be protected by IPsec [13, 11, 12]
       to guard against malicious Router Advertisements.  The IPsec
       protection MUST provide sender authentication, data integrity
       protection, and replay protection, covering the Router
       Advertisement.

       < I initially considered putting this in the tunnel header,
         but most tunneled packets from the home agent to the mobile
         node don't require IPsec, so this would probably require
         special logic in the tunnel code to handle. I expect
         applying IPsec to the inner header would be easier and
         will still achieve the intended security. >

    -  The packet MUST include a Binding Request destination option
       after the IPsec Authorization or Encapsulation header.

       < Putting the Binding Request here allows the mobile node
         to strip off the outer IPv6 headers the same as it would
         do for any other tunneled message. >

    -  The Binding Request destination option MUST include a Unique
       Identifier Sub-Option (Section 5.5), with the unique identifier
       in the sub-option data set to a value different than that in
       any other Binding Request sent recently by this node.  The word
       "recently" here means within the maximum likely lifetime of a
       packet, including transit time from source to destination and
       time spent awaiting reassembly with other fragments of the same
       packet, if fragmented.  However, it is not required that a source
       node know the maximum packet lifetime.  Rather, it is assumed
       that the requirement can be met by maintaining a simple 16-bit
       "wrap-around" counter to generate unique identifiers for Binding
       Requests that contain a Unique Identifier Sub-Option, incremented
       each time a Binding Request containing a Unique Identifier
       Sub-Option is sent.

       < Its going to be difficult to track the status of this
         binding request when the mobile node has no home address
         and has not yet created a binding. Once again, creating a
         binding for the mobile node's link-local address would help. >

On page 92, replace the rules for validating
received router advertisements on the mobile node:
==================================================

   When a mobile node receives a tunneled Router Advertisement, it MUST
   validate it according to the following tests:

    -  The Router Advertisement was received over a tunnel whose
       entry point was the same as the home agent address to which the
       mobile node last sent an accepted "home registration" Binding
       Update to register its primary care-of address. If no home
       registration exists yet, the tunnel entry point must be the
       same as the exist point of a tunnel through which a
       Router Solicitation was recently transmitted.

    -  The inner IPv6 packet MUST be protected by IPsec [13, 11, 12]
       to guard against malicious Router Advertisements.  The IPsec
       protection MUST provide sender authentication, data integrity
       protection, and replay protection, covering the Router
       Advertisement.

    -  The inner packet contains a Binding Request destination option.

    -  The Binding Request option contains a Unique Identifier
       Sub-Option.

Modify my previous proposal for sending Router
Solicits from the mobile node to the home agent:
================================================

The mobile node must construct and tunnel such a Router Solicitation
packet using IPv6 encapsulation [4] as follows:

 -  The tunnel entry point is the mobile node's primary care-of
    address.

 -  The tunnel destination is the home agent's global IP address.

 -  The Source Address of the inner IPv6 header is set to the
    unspecified IP address (0::0).

 -  The Destination Address of the inner IPv6 header is set to
    the all routers multicast address.

 -  The tunnel header MUST be protected by IPsec [13, 11, 12] to guard
    against malicious Router Solicitations.  The IPsec protection
    MUST provide sender authentication, data integrity protection,
    and replay protection, covering the Router Solicitation.

    < I think we should keep this requirement if responding to
      unauthorized probes for address information could be a bad
      thing at some sites. >

    < If we decide link-layer address bindings are a good thing,
      we could send a binding update in the inner IP packet
      for the link-layer address, and specify an Alternate Care-Of
      suboption containing the mobile node's primary care-of
      address. >

 - The Router Solicitation's source link-layer address
   option MUST be omitted.

    < We may wish to change this given home subnet link layer
      address in the inner IP header and a possibility of a
      binding for the link layer address. >

Modify my previous proposal for how the Home Agent
receives Router Solicitations from Mobile Nodes
=================================================

The Router Solicitation may include a Binding Update
destination option. The processing requirements described
here for the Router Solicitation assume the Binding Update
destination option was processed first. The home agent MAY
return a single packet containing both the resulting Binding
Acknowledgment destination option and a Router Advertisement.

 < Remove paragraph on how to handle binding
   updates included with the router solicitation
   unless we implement bindings for a link-layer
   addresses >

When a home agent receives a tunneled Router Solicitation from
a mobile node on a remote network, it MUST validate it according
to the following tests:

 - The inner packet is protected by IPsec [13, 11, 12] to guard
   against unauthorized probes for home subnet information.  The
   IPsec protection provides sender authentication, data integrity
   protection, and replay protection, covering the Router
   Solicitation.

    < All the other tests are unnecessary with tunnels
      unless we implement bindings for link-local
      addresses. >

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Thursday, November 09, 2000 4:38 PM
> To: Mattias Pettersson; Powell, Ken
> Cc: Mobile IP Mailing List
> Subject: Appendix
>
>
>
> Hello folks,
>
> Here is a stab at an appendix.  It needs proofreading, but
> I have to go for now and I thought it would be better to
> send something defective for now and touch it up more later.
>
> My opinion is that a Binding Update is needed, and if it takes
> another few hundred milliseconds, that's O.K.  So, I retained
> that step for the part after the Router Advertisement was
> received by the mobile node.  However, this is of course up
> for discussion.
>
> I reckon the hard part will be to manage the identification
> for the mobile node.  As Hesham mentions, NAI could be used
> for this.  However, I am sure that everyone agrees that right
> now is not the time for trying to complete that discussion.
>
> Regards,
> Charlie P.
>
> =====================================================================
>
>
> A. Remote Home Address Configuration
>
>    The method for initializing a mobile node's home addresses on
>    power-up or after an extended period of being disconnected from
>    the network is beyond the scope of this specification.  Whatever
>    procedure is used should result in the mobile node having the same
>    stateless or stateful (e.g., DHCPv6) home address autoconfiguration
>    information it would have if it were attached to the home network.
>    Due to the possibility that the home network could be renumbered
>    while the mobile node is disconnected, a robust mobile
> node would not
>    rely solely on storing these addresses locally.
>
>    A mobile node MAY generate a temporary home address using the
>    following information:
>
>     -  the subnet prefix from the home network's mobile agent anycast
>        address, and
>
>     -  the globally unique interface identifier that would have been
>        used to generate the link local address if the mobile node were
>        attached directly to the home network.
>
>    Such a temporary address could be used to establish a binding with
>    a home agent in the absence of any other known home addresses.  It
>    could be created with short valid lifetime and a preferred lifetime
>    of zero to ensure a quick transition to other addresses generated
>    when stateless or stateful (DHCPv6) address autoconfiguration runs.
>
>    Such a mobile node could initialize by using the following
> procedure:
>
>     1. Query DNS for the home network's mobile agent anycast address.
>
>     2. Generate a care-of address using stateless or stateful
>        autoconfiguration.
>
>     3. Send a Home Agent Address Discovery Request message to the home
>        network.
>
>     4. Receive Home Agent Address Discovery Reply message.
>
>     5. MN picks one Home Agent and tunnels an Router
> Solicitation to it.
>
>           Outer src = care-of address
>           Outer dst = Home Agent's global address
>           Inner src = 0:0:0:0:0:0:0:0 (unspecified address)
>           Inner dst = Home Agent's global address
>
>
>     6. Home Agent returns a Router Advertisement, covered by AH. An SA
>        has to be set up between MN's CoA and the HA. How this is done
>        is out of scope, but MN and HA have some shared secret
> or can be
>        verified by some agent.
>
>        The Router Advertisement is returned by tunneling, as follows:
>
>           Outer src = HA's global address
>           Outer dst = care-of address
>           Outer src = HA's home subnet link-local address
>           Inner dst = all-nodes multicast address
>
>
>     7. Mobile node parses Router Advertisement and configures all
>        prefixes and addresses according to the method stated
> there.  If
>        the the M or O flags are set in the router
> advertisement, follow
>        the stateful (DHCPv6) configuration procedures.
>
>     8. Send binding update option(s) to establish bindings for the new
>        home addresses.
>

---

From: Mattias Pettersson <[email-masked]>
Date: Mon, 13 Nov 2000 14:41:16 +0100

Hi all,

Again Ken, thanks for doing this study.

> On page 70, replace the tunneling technique with:

This idea of registering the link-local address is very interesting. The
Mobile Node could carry out everything from RS/RA to DAD and DHCPv6
itself, without proxy functions in the HA. But somehow the idea in the
I-D is to not allow mobility for link-local addresses.

There are both pros and cons of forwarding link-local packets to the MN.
The MN gets more aware of what's happening on the home link, but at the
same time a lot of unecessary traffic is tunneled to the MN.

>          do for any other tunneled message. >

I believe the HA should only include the BR when the RA is transmitted
on HA initiative. If the RA is being sent in response to a RS from the
MN, then the BR should be omitted.

This wouldn't be an implementation issue, would it?

>          binding for the mobile node's link-local address would help. >

So, if we skip BR in this case, we don't have this matching problem.

On the other hand, I kind of like the idea of first registering the
link-local address, carry out the RS/RA, and then configure the home
addresses and send a BU for them. Link-local address registration could
be left to expire, after that.

> received router advertisements on the mobile node:

Ok. Since the RA in return anyway requires this SA, it doesn't matter if
we create it at this stage.

>       suboption containing the mobile node's primary care-of

Yeah!