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

From: "Powell, Ken" <[email-masked]>
Date: Tue, 7 Nov 2000 13:49:05 -0500

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'd like to open up for a simple procedure, see below.

I had asked about a similar procedure before. I believe
Charlie was thinking about adding it in an appendix as an
FYI. That made sense to me given that the procedure simply
showed how a mobile node could use existing protocol
mechanisms to initialize itself. It didn't really add
any protocol requirements. I also agree with Charlie
that we should not block the current spec to sort
out all details of initialization.

<snip>

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.

> 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.

> 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?

> Forget if I mentioned 8.

Thanks, I was going to ask about that.

> Still a remark of the configuration alternatives as was
> suggested could be useful in the draft:

I agree. But I'm concerned this may take quite a bit of
effort to agree upon the details. See example questions below.

> 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.

Would you add the following as another option?

  1D. Store prefix in DNS.
       - Must assume a prefix length.

> 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.

> 2A. Manual:
>     - not the best idea. MN can't check its Home Address
>       for DAD.

DAD must be used even with manual address configuration.

>     - 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.

>
> Ken Powell wrote:
>
> > Item 3
> > ======
> >
> > 10.x Sending Router Solicitations to a Home Agent
> >
> > A mobile node that uses stateless address auto configuration on
> > its home subnet could miss significant home subnet configuration
> > changes while disconnected. Such a mobile node MAY request updated
> > prefix information when it detects a possibility that its current
> > home subnet address information is inaccurate by sending a Router
> > Solicitation to the home agent. The mobile node must construct
> > such a Router Solicitation packet as follows:
> >
>
> I want this also the first time when MN has never received an
> RA from its home link.

This is one of the cases I was thinking of when I wrote the clause
"when it detects a possibility that its current home subnet address
information is inaccurate". I don't have any problem if Charlie wants
to add this as an example.

>
> >  -  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.

> 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.

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.

It seemed much simpler and less disruptive to the current
spec to let the mobile node generate a temporary address.

> 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).

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

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 9 Nov 2000 15:28:40 +0100

Hi Ken,

> is broken. Further details below (along with plenty of other

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.

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.

> out all details of initialization.

That's what I want.

> future possibly using AAA that covers IPsec requirements

Ok. I accept this as one possible way.

> send the BU option for its temporary address with the

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.

> Would listing such steps in an appendix be OK with you?

Fine.

> 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.

>        - Must assume a prefix length.

Ok.

> 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.

> 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.

The current spec will only work if the MN at day 1 starts on the home
subnet.

> 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.

[...]

> address would only be allowed if it was based on a globally

I don't see why the exact look of the address would matter.

> IPv6 header violated the base spec.

I think we can always tunnel ourselves away from problems... :)

> update/acknowledge option to a tunneled RS/RA.

I would try to avoid BUs/BAs now.

> spec to let the mobile node generate a temporary address.

Ok, I see.

> 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?

>       address to configure the mobile node's home

So, I'd like to refine my proposed procedure once again:

1. MN somehow knows it's home prefix (manual, name, AAA & NAI, ...)
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.
        Outer src= care-of address
        Outer dst= HA's global address
        Inner src= whatever... CoA or LL maybe.
        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.
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.
  4c. If future methods are used: tunnel requests through home agent.
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.

/Mattias