Subject: Re: [MOBILE-IP] How Mobile IPv6 should handle home networkrenumbe ring

From: "Powell, Ken" <[email-masked]>
Date: Thu, 9 Nov 2000 13:41:50 -0500

Mattias,

I fear we are not resolving this very fast. The only
clean solution I see that would satisfy both of us
is to use tunnels for RS/RA, but that means plenty
of work real fast. I don't want to start a concrete
proposal unless others think its worth the effort.

Detailed comments below.

> -----Original Message-----
> From: Mattias Pettersson [mailto:[email-masked]]
> Sent: Thursday, November 09, 2000 9:29 AM
> To: [email-masked]
> Subject: Re: [MOBILE-IP] How Mobile IPv6 should handle home
> networkrenumbe ring
>
>
> Hi Ken,
>
> "Powell, Ken" wrote:
>
> > Mattias,
> >
> > I think you have a very important initialization concern,
> > primarily because it impacts the way RS's and RA's are
> > sent between the home agent and the mobile node. It boils
> > down to a question of can we assume the mobile node will
> > always have a home address before the first RS/RA exchange?
> > I hope so, because if not, the technique for sending RS/RA
> > is broken. Further details below (along with plenty of other
> > stuff).
> >
>
> 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.

Yes, I was shooting for that goal too.

>
> There are two different uses of RS/RA:
>
> 1. HA sends RA to MN to synchronize MN with renumbering. An
> ack is needed. BU from MN to HA in return has been chosen for
> this. Both RA and BU needs AH. We could theoretically choose
> another ack method.
>
> 2. MN sends RS to HA to learn on home link autoconfiguration
> (prefixes, address configuration method, etc). HA replies
> with RA. We don't need a BU after this. RS doesn't necessarily
> need a AH, but the RA must have it. We could secure it by other
> means than using the home address.

I think unless we find another ACK method, I would prefer to
keep the BU at the end of use 2. This is a tradeoff between
simplicity and efficiency (i.e., "always ACK" vs "ACK except
under certain conditions").

>
> >
> > Following your proposed list of initialization steps:
> >
> > > 1. The MN finds out its home prefix.
> >
> > One possible option for this was to statically configure in
> > the mobile node the fully qualified domain name of the home
> > agent's anycast address. This would allow the mobile node to:
> >
> > 1a. Query DNS for the home agent's anycast address.
> > 1b. Temporarily use the prefix from the home agent's
> >     anycast address for the home subnet prefix.
> > 1c. Use the temporary home subnet prefix and a globally
> >     unique interface id to autoconfigure a temporary home
> >     subnet address for the mobile node.
> >
> > I'm hoping for a better technique to be defined in the
> > future possibly using AAA that covers IPsec requirements
> > as well.
> >
>
> Ok. I accept this as one possible way.
>
> >
> > > 2. MN performs DHAAD to find unicast address of an HA.
> > > 3. MN sends RS to HA.
> > > 4. HA sends RA with prefix list to MN.
> >
> > Given the current method of how RS and RA are exchanged
> > between the mobile node and home agent, you have to have
> > a global scope home address for the mobile node by step 3.
> > You also have to have a valid binding between the mobile
> > node and the home agent for the home agent to return the
> > RA. Therefore, it makes sense for the mobile node to
> > send the BU option for its temporary address with the
> > initial RS.
>
> Yes, given the current method. But if I suggest a new way
> of automagically configure the home address, exactly as it
> would have been done on the home link, the current method
> has to be slightly modified. I think we introduce more
> modularity/independence if MIPv6 can make use of existing
> address allocation methods, rather than introducing a new,
> still not sorted out, method that only MNs use.

OK, I think we have the same objectives here.

> >
> > > 5. MN builds Home Addresses for all prefixes, by using
> > >address method stated in prefix info.
> > > 6. MN registers each Home Address.
> > > 7. HA might help in address configuration (e.g. DAD)
> > > 8. DNS should be updated, depending on address configuration
> > > method (it should be done by the MN at this point, not
> > > earlier, IMO).
> > >
> > > Ok. Let's agree on leaving the big issues out of scope.
> >
> > Would listing such steps in an appendix be OK with you?
>
> Fine.
>
> > > Home Prefix (needed to find Home Agents) conf alts:
> > > 1A. Manual:
> > >     - won't survive home network renum when MN is off.
> > > 1B. Always start home or user interaction (button...):
> > >     - same, plus need to start at home, a difficult demand
> > > 1C. AAA:
> > >     - will survive anything.
> >
> > I have no idea what AAA does for us on this. I wouldn't
> > assume it could be used as an alternative to stateless
> > address autoconfiguration or DHCPv6.
> >
>
> Here we are talking about finding out the home prefix, not
> the home address.
>
> Please see Hesham's comment in another mail.

Is the real goal to find the home agents, not necessarily
the home prefixes? Perhaps thats what confused me. I
consider a mobile would want to get most of its home
prefix information, complete with lifetimes and flags,
from stateless or statefull address autoconfiguration
later on.

>
> >
> > Would you add the following as another option?
> >
> >   1D. Store prefix in DNS.
> >        - Must assume a prefix length.
>
> Ok.
>
> > >
> > > Home Address conf alts:
> >
> > Why have two separate lists for home prefix and home address?
> > It seems to me the technique for determining the home address is
> > closely tied to the method for determining home prefix.
>
> No. You need the home prefix to find a home agent that can
> tell you in an RA how to configure your home address.

I think you only need a single home agent anycast address.
The address can be derived from the prefix if you have one,
but in many cases, it could be easier to get the anycast
address directly.

>
> > > 2A. Manual:
> > >     - not the best idea. MN can't check its Home Address
> > >       for DAD.
> >
> > DAD must be used even with manual address configuration.
>
> Charlie and others: I can't find anywhere in the I-D that the MN
> is required to check its Home Address for DAD, other that during
> renumbering. If the MN is given an address from start (hard coded
> or statelessly created by combining home prefix and interface
> token), it must set the D-flag in the initial BU to the HA. It
> must do this every time the HA doesn't guard the address.

Saw your other message on this, good catch.

>
> The current spec will only work if the MN at day 1 starts on the home
> subnet.
>
> > >     - What is the relationship between a manual address and
> > >       the renumbered autoconfigured address?
> > > 2B. Autoconf by RA from Home Link (either directly from Home
> > >     Link or tunneled by HA):
> > >     - MN will be configured just as if it was home.
> > > 2C. AAA:
> > >     - then addresses are configured and distributed by other
> > >       means than IPv6 ND autoconf (state{ful,less})
> > >     - if renumbering occurs MN must get new address though
> > >        AAA rather than RA.
> >
> > Could AAA be defined to work with stateless address
> > autoconfiguration or DHCPv6 instead of as an alternative?
> > Perhaps AAA could somehow bootstrap these other mechanisms.
> > I know nothing about AAA beyond the idea that it provides
> > information necessary to establish a security association
> > between the home agent and the mobile node.
>
> >
> > >
> > > 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:
> >
> > I don't think we can do this without changing the way RS's and
> > RA's are sent. I think this issue is very important to resolve
> > now because a change later to the method for sending RS's and
> > RA's won't be upward compatible.
>
> Yes, I don't want to lock out such ideas in the draft. If we need to
> finish this revision of the I-D urgently, we can go for this solution
> right now. Later we have two options:
> 1. fix it in future revisions of MIPv6... rev 17 or so... ;)
> 2. put this in a draft that overrides MIPv6 in certain areas.
> Then we will of course have backward compatibility problems.
>
> [...]
>
> > >
> > > >  -  The Source Address in the packet's IPv6 header MUST be set
> > > >     to the mobile node's primary care-of address.
> > > >
> > > >  -  The packet 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.
> > > >
> > > >  - The packet MUST include a Home Address destination option,
> > > >    giving the mobile node's home address for its current
> > > >    binding.
> > > >
> > > >  - The packet MUST include a Binding Update destination option
> > > >    as described in section 10.6 if a current binding does not
> > > >    yet exist. Otherwise, it MAY include a Binding Update
> > > >    destination option.
> > >
> > > Here we have a problem. If the MN doesn't have a home address
> > > it can't provide any at this point (step 3 above).
> >
> > Agreed. This is a problem for both the RS and RA. The way they
> > are exchanged requires that the mobile node have at least one
> > home address first. Some months back, I asked if it would be
> > reasonable for the mobile node to generate a temporary address
> > (very short lifetime) to get past this exchange. Such an
> > address would only be allowed if it was based on a globally
> > unique interface id.
>
> I don't see why the exact look of the address would matter.

The global interface id restriction was based on the idea that
the mobile node was generating and using the interface id from
local information only without running DAD first. The real
objective was to to ensure there was near zero chance of a
duplicate address with another node. It doesn't really matter
how this objective is met. This just seemed a simple way to
do it.

>
> > > Is there a way we can leave this open for a lost MN with no
> > > home address?
> >
> > The only way I could think of was to always tunnel the RA and
> > RS per RFC 2473 instead of using the home address option
> > and the routing header. I tried to think of ways to
> > initialize using link-local addresses or the unspecified
> > address for the mobile node, but doing so without a tunneled
> > IPv6 header violated the base spec.
> >
>
> I think we can always tunnel ourselves away from problems... :)

Or into more more problems ;)

>
> > The problem with switching to RFC 2473 tunneling is that
> > we would have to clearly define how to secure the message,
> > how to associate a tunneled message to a specific binding,
> > what to do if no binding exists, and how to attach a binding
> > update/acknowledge option to a tunneled RS/RA.
>
> I would try to avoid BUs/BAs now.

OK.

>
> >
> >
> > It seemed much simpler and less disruptive to the current
> > spec to let the mobile node generate a temporary address.
>
> Ok, I see.
>
> >
> >
> > > However, we must still secure the protocol, of course, but we
> > > can do this
> > > without a home address.
> > >
> > > Are the Home Address Option and Binding Update really needed,
> > > unless the HA is
> > > expecting an ack?
> >
> > Hmm, I hadn't thought of this. If I understand you correctly,
> > your suggesting the mobile node send the RS directly from
> > its care-of address to the home agent with no home address
> > option? I suppose it could work, but I'm not comfortable
> > with it. This implies to me that the home agent returns
> > the RA back to the mobile node's care-of address with no
> > routing header. The home agent would normally put the mobile
> > node's home address in the routing header, but the mobile
> > node doesn't have a home address configured yet. This
> > solution feels to me like exchanging RS's and RA's over one
> > interface (with the care-of address) to configure another
> > interface (with the home address).
>
> Correct! But the home address interface could under some
> circumstances be
> regarded as lying on top of other more physical interfaces where the
> care-of addresses are. Isn't this exactly what happens during
> tunneled RA
> from HA to renumber the MN?

Yes, but the existance of the tunnel header is an explicit
signal that the intended destination is the home network
pseudo interface insteaded of the care-of network
physical interface. The current use of routing header
and home address option do the same thing. I think we
need some form of explicit marker that indicates which
interface the RS/RA apply to.

>
> >
> > Of the three options for handling RS's and RA's, my
> > preference is:
> >
> >  1st: Keep the current mechanisms which require that the
> >       mobile node somehow get an initial home prefix and
> >       address before communication starts. Method to be
> >       specified later.
> >
> >  2nd: Use RFC 2473 style tunneling.
> >
> >  last: Exchange RS's and RA's directly between a
> >       the home agent and the mobile node's care-of
> >       address to configure the mobile node's home
> >       addresses.
> >
> > Ken
>
> So, I'd like to refine my proposed procedure once again:
>
> 1. MN somehow knows it's home prefix (manual, name, AAA & NAI, ...)

Could you change this to "knows its home agent anycast address"?

> 2. MN sends RS to HA
>   2a. MN has to find an HA first by DHAAD.
>   2b. For DHAAD MN needs to send ICMP HAAD Request to anycast address
>   2c. One HA replies with Home Agents list.
>   2d. MN picks one HA and tunnels an RS to it.

Could you give DHAAD procedure and home agent selection as
step two, then have separate step 3 for "MS sends RS..."?

>         Outer src= care-of address
>         Outer dst= HA's global address
>         Inner src= whatever... CoA or LL maybe.

Suggest using the "unspecified address" for the Inner src,
same as if the node were on-link.

>         Inner dst= ff02::x
>         This packet doesn't need AH. I don't see this as a
>         possible DoS threat.
> 3. HA returns an RA. This message must not include a binding
>     request (MN is polling).
>     This packet must be 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 someone.

How does the RA get returned? I think this needs to specify
using RFC 2473 style tunnel encapsulation instead of a routing
header. The mobile node doesn't have a global home address yet.
Would the following addresses make sense?

          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

> 4. MN parses RA and configures all prefixes and addresses
>     according to the method stated there.
>   4a. If stateless is used: form Home address statelessly and
>       let HA run DAD for it.
>   4b. If stateful is used: talk to DHCPv6 server to receive
>       an address. Currently, DHCPv6 is based on link- or
>       site-local multicast. MN might have to tunnel the request
>       and reply via the HA.

I don't think we should assume anything about how statefull
configuration is performed. How about say:

     4b. If the the M or O flags are set in the router
         advertisement, follow the statefull (DHCPv6)
         configuration procedures.

>   4c. If future methods are used: tunnel requests through home agent.

I don't see any reason to restrict future configuration methods
to always working through the home agent. I'm assuming your
describing requests of some as yet undefined protocol.

> 5. MN registers with HA by sending BUs for all Home Addresses.
>    This time a new SA is set up between MN and HA. HA checks DAD
>    if needed.
>
> 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.

Looks like we are headed for parallel ways to send RA/RS
to avoid a parallel home address configuration method.
I'm not at all happy with doing that. I would rather see
us adopt a single consistent method for exchanging RS/RA.
If we have to change how RS/RA are sent, lets do it the
right way now.

Ken

---

From: Mattias Pettersson <[email-masked]>
Date: Fri, 10 Nov 2000 13:27:55 +0100

Hi Ken,

I believe Charlie's new Appendix sums up this discussion pretty well. I
haven't got all my requests in it, but I have to say it is an ok middle
way.

> but in many cases, it could be easier to get the anycast

If you are querying the DNS, yes anycast addresses are better.

Ok, I see.

> interface the RS/RA apply to.

Well... yes. You are right. Need to think about this.
> describing requests of some as yet undefined protocol.

That's right.

> If we have to change how RS/RA are sent, lets do it the

I could go with the Appendix solution at the moment.

/Mattias