Subject: Tunneled RA unspecified addr issue

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 12 Feb 2001 20:02:11 -0800

Hi folks, I am back with the new puzzle of the week, this time regarding
a Rtr Solicit from a MN before it has configured its Home Addr.

Suppose a mobile node is away from home and the following events have
already happened:

1. Mobile has configured a (global) Care-Of Address
2. Mobile has determined its home network prefix and Home Agent address.

Now, the mobile wants prefix info from the home link so it can configure
its Home Address.

3. Mobile sends Tunneled Router Solicitation (according to [MIPv6-13,
10.16]), encapsulated with:
  a. Outer Dest = Home Agent
  b. Outer Source = Care Of Address
  c. Inner Dest = Home Agent
  d. Inner Source = 0::0 (Unspecified).

- So the HA receives this packet, throws away the outer IPv6 header and
is left with the inner packet header and payload (RS). Now it prepares
the RA with its prefix info and the prefix info of other HAs on the
link.

4. HA sends a Tunneled Router Advertisement (according to [MIPv6-13
9.8.3]):
  a. Dest = 0::0
  b. Src = Home Agent
  c. HomeAddrOpt Src = COA

But notice that we probably *no longer have the COA* to stick there,
since it was in the wrapper of the encapsulated IPv6 packet, and was
thrown away. "Bummer."

*** I would propose a change to the draft, which is as follows:
The MN sends the initial RS (no longer encapsulated) with an home
address option as follows:
  a. Dest = Home Agent
  b. Source = Care Of Address
  c. Home Addr Opt Source = Home Address, or if not configured, 0::0
(unspecified).
The Home Agent will know by the presence of the option that the RS
originates from a MN and may include extra prefixes absent in vanilla
RAs, and it will still have the COA around to reply to.
Let's continue.
***

4'. Home Agent receives this TRS, and prepares a Router Adv. with normal
prefix info AND prefix info for other HAs on the link. It can now send
to the MN (as if it had found a binding from 0::0 -> COA) with:
  a. Dest = 0::0
  b. Source = HA
  c. RouteHdr0 dest = COA

This is scary, but it follows MIPv6 semantics, and I think it would be
delivered to the unspecified address due to the Routing Header. Is this
correct?

5. MN receives RA. MN Notices that RA has TTL < 255. MN silently
discards RA.
(note that this would have been a problem at the HA as well.)

*** I would propose changes to the draft,as follows:
HAs receiving RSs with HomeAddr Options do not verify TTL = 255.
MNs receiving RAs with Routing Headers do not verify TTL = 255.
***
These are special cases of RS and RA where mobility info is included in
the message, and they are routed across networks, so TTL can be anything
> 0.
Let's continue:

5'. MN receives TRA, notices that it has a Routing Header indicating
mobility info. It verifies the RA but ignores TTL, and then hands the
prefix info to the Mobile IP code so it can be used to construct/modify
the Home Address.

6. Success

Comments?

-- 
T.J. Kniveton
NOKIA Research Center

---

From: "Powell, Ken" <[email-masked]>
Date: Wed, 14 Feb 2001 17:35:05 -0500

Resending: Used incorrect address in original.

-----Original Message-----
From: Powell, Ken 
Sent: Wednesday, February 14, 2001 4:23 PM
To: 'T.J. Kniveton'; [email-masked]
Subject: RE: Tunneled RA unspecified addr issue

> -----Original Message-----
> From: T.J. Kniveton [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2001 3:23 PM
> To: Powell, Ken
> Cc: [email-masked]
> Subject: Re: Tunneled RA unspecified addr issue
> 
> 
> > > delivered to the unspecified address due to the Routing
> > > Header. Is this correct?
> > 
> > I'm a bit confused here. Is your list of addresses represent what
> > the home-agent daemon would specify at the API? I would expect
> > to see the following on the wire:
> > 
> >   a. Dest = COA
> >   b. Source = HA
> >   c. RouteHdr0 dest = 0::0
> 
> No, the idea is that the packet is routed to the mobile node 
> because of
> the Routing Header, which would supercede the IPv6 dest addr. Once it
> gets there, the routing header is removed by the MN (and it knows this
> is a MIP packet with special handling), and then the IPv6 packet is
> destined for the 0::0 address which the MN used as source. The purpose
> of using an unspecified address is mainly for symmetry -- I suppose it
> could also be the COA, and the rule could be "if you receive a routing
> adv. destined for a Global address, with a TTL < 255, you know it's a
> MIPv6 tunneled RA". This might break security associations, but
> presumably they don't exist yet if there is no HA configured.

I'm still confused what you mean by "supercede". I understood from RFC
2460 page 16 that routers don't look at the routing header until the
message reaches the address specified in Dest. The message won't go
anywhere if it sends the packet with a Dest of 0::0.

Ken

---

From: "Powell, Ken" <[email-masked]>
Date: Wed, 14 Feb 2001 17:33:43 -0500

Resending, had incorrect address in original.

-----Original Message-----
From: Powell, Ken 
Sent: Tuesday, February 13, 2001 1:09 PM
To: 'T.J. Kniveton'; [email-masked]
Subject: RE: Tunneled RA unspecified addr issue

I've been focused on other stuff since draft 13 came out,
so I haven't been able to read it in detail yet. Thanks
for spotting these concerns.

> From: T.J. Kniveton [mailto:[email-masked]]
> Sent: Monday, February 12, 2001 11:02 PM
> To: [email-masked]
> Subject: Tunneled RA unspecified addr issue
> 
> 

I thought we had agreed to a different method to send the router
solicit that didn't use the encapsulated header. The discussion
was very confusing back then, so I could be wrong.

> since it was in the wrapper of the encapsulated IPv6 packet, and was

This also violates the addressing architecture, RFC 2373 section
2.5.2:

   The unspecified address must not be used as the destination address
   of IPv6 packets or in IPv6 Routing Headers.

This is one of the problems that led to the appendix A idea
of generating a temporary home address.

Note also that the Router Advertisement example in Appendix A
does not follow this format. I think Appendix A should be
corrected.

> RAs, and it will still have the COA around to reply to.

Yes. This is the format I thought we had agreed to. Using the
unspecified address is an interesting variation on the theme. It
seems like an obvious thing to do when the mobile node doesn't know
its home address yet. Unfortunately, it leads to some complications
in the returned router advertisement. More on that below.

  a. Dest = COA
  b. Source = HA
  c. RouteHdr0 dest = 0::0

We are back to that "unspecified address must not be used ...
in IPv6 Routing Headers" requirement in the addressing architecture.

Another alternative would be to use an AllNodes multicast address
for RouteHdr0 dest, but that violates RFC 2460 Section 4.4:

   Multicast addresses must not appear in a Routing header of Type 0, or
   in the IPv6 Destination Address field of a packet carrying a Routing
   header of Type 0.

In either event, the message must be IPsec protected. What address is
the security association based on? Normally, it would be the final
destination, but does that make sense with the unspecified address?

> the message, and they are routed across networks, so TTL can 

Good catch. Given that the router advertisement must be protected
by IPSec, I don't see a problem relaxing the TTL rule here.