Subject: Re: [nemo] Link local addresses

From: Alexandru Petrescu<[email-masked]>
Date: Tue, 01 Apr 2003 15:19:57 +0200

I'm trying to understand this...

Erik Nordmark wrote:
>> I would suppose that this is an issue of the link-local 
>> addressing of MR in general.  The use of DHCPv6 is but one 
>> "link-local addressing" issue for MR.  The other link-local 
>> addressing issues for MR come from the use of routing protocols 
>> between MR and HA; another link-local address issue is also the 
>> HA sending RA's to MR (or MH for that matter); yet another is 
>> from multicast MLD between MR and HA, that also uses link-local 
>> addressing.
> 
> What exists in MIPv6 is a prohbition from _forwarding_ packets with
>  link-local addresses out over the tunnel to the MN.
> 
> But I think all the cases above are about operating a protocol 
> which uses link-local addresses on the link which is the tunnel; 
> the link-local addresses used on the tunnel can be used in that 
> case since there isn't any forwarding taking place. Perhaps this 
> isn't clear enough in the specs.

Aha.  There's a particular phrase in the Mobile IPv6 that I would like
to better understand.  When describing the HA behaviour when
intercepting packets, it says:

    "However, packets addressed to the mobile node's link-local address
     MUST NOT be tunneled to the mobile node."

With the previous interpretation, that would become:

    "However, packets addressed to the mobile node's link-local address
     MUST NOT be forwarded to the mobile node, but they SHOULD (if L=1)
     be tunneled over the virtual tunnel interface MN-HA."

Is this the intended meaning?

> Thus in the particular case of DHCPv6, the HA would operate a 
> DHCPv6 agent (either a server or a relay) on the tunnel interface.

I think HA could operate a DHCPv6 agent over the tunnel interface, but
only when MN is not at home, right?

Also, I wonder whether it would be benefic that the entire scheme
works with three separated entities: DHCPv6 agent, the HA and the BR
in the home domain, on the same home link (as opposed to having all
three entities co-located in the BR).

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 1 Apr 2003 17:31:57 +0200 (CEST)

> Is this the intended meaning?

No, since this is in the context of intercepting packets destined to
the mobile node. The need for DHCPv6 etc is to be able to _originate_ (not
forward) packets on the tunnel link which uses link-local addresses.

The formation of link-local addresses for tunnels is described in RFC 2473.
Note that the MNs link-local address on the tunnel interface might be different
than the link-local address the MN has on its non-tunnel interface when it is
at home, but they might also be the same. In any case it doesn't matter since
the link-local addresses only need to be unique per link and the tunnel is a
different link than the non-tunnel.

> only when MN is not at home, right?

*If* there was a tunnel when the MN was at home it could oerate
DHCPv6 while at home. MIPv6 doesn't have a tunnel while at
home. 
Point is this is not an issue for DHCPv6 - it is an issue whether the
tunnel exists or not.
If Nemo doesn't use a tunnel at home, presumably DHCPv6 for prefix delegation
could be used over the home link.

> three entities co-located in the BR).

What's a BR? MR? Border Router?
And DHCP can already have two levels - a relay agent and a server.

  Erik

---

From: Alexandru Petrescu<[email-masked]>
Date: Tue, 01 Apr 2003 19:37:32 +0200

>  link-local addresses out over the tunnel to the MN.

I see, so it must be something related to the below rfc2460 text:

    "Routers must not forward any packets with link-local source or
     destination addresses to other links."

I could better grasp it that way.

Alex

---

From: Alexandru Petrescu<[email-masked]>
Date: Tue, 01 Apr 2003 20:27:50 +0200

Erik Nordmark wrote:
> No, since this is in the context of intercepting packets destined 
> to the mobile node. The need for DHCPv6 etc is to be able to 
> _originate_ (not forward) packets on the tunnel link which uses 
> link-local addresses.

When one considers that the HA and DHCP agent are co-located in one
entity, then yes.  If DHCP Agent is a relay, and HA is a one-interface
  machine (both connected on the home link) then the HA would need to
"forward" link-local addressed packets, if the virtual link between HA
and MR is torn down when MR at home, if I understand it correctly.

> The formation of link-local addresses for tunnels is described in 

That sounds familiar, but I'm trying to find the formation of
link-local addresses in rfc2473 and I can't?  I know non-ether
link-locals defined in rfc2529 (v6 over v4) and rfc2491 (v6 over NBMA).

> Note that the MNs link-local address on the tunnel interface might
>  be different than the link-local address the MN has on its 
> non-tunnel interface when it is at home, but they might also be the
>  same. In any case it doesn't matter since the link-local addresses
>  only need to be unique per link and the tunnel is a different link
>  than the non-tunnel.

A-ha, I see...

>> I think HA could operate a DHCPv6 agent over the tunnel 
>> interface, but only when MN is not at home, right?
> 
> 
> DHCPv6 while at home. MIPv6 doesn't have a tunnel while at home. 
> Point is this is not an issue for DHCPv6 - it is an issue whether 
> the tunnel exists or not. If Nemo doesn't use a tunnel at home, 
> presumably DHCPv6 for prefix delegation could be used over the home
>  link.

Ok, agreed here.

> What's a BR? MR? Border Router? And DHCP can already have two 
> levels - a relay agent and a server.

(or a chain of relays?)

I was referring to BR as Border Router.  Wondered if a configuration
like this is supposed to be made to work ok (I draw real physical
links only).

    ------    ----                           /
   | Relay|  | HA |                         /
    ------    ----               ----------/
      |         |       ----    |          |
    -------------------| BR |---| Internet |
        |               ----    |          |
      ----    -----              ----------\
     | MR |  | LFN |                        \
      ----    -----                          \
        |       |
        ---------

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 4 Apr 2003 11:20:59 +0200 (CEST)

> and MR is torn down when MR at home, if I understand it correctly.

Why is that? If there is no tunnel when the MR is at home then
the system needs to be designed so that the MR can perform
DHCPv6 etc without necessarily going through the HA. For instance, it
might go through some other DHCP relay.

Example with one MR at home and another away:

	             DHCP server
	                  |
	              ---------------
	              |             |
	              R1           R2 with DHCP relay
	              |             |
	home link --------------------------
                  |                     |
	          HA with DHCP relay   MR1
	          !
	          ! (tunnel to MR2)
	          !
	         MR2

In this case the HA might be a DHCP relay on just the tunnels, or it might
also be a DHCP relay on the home link.
It wouldn't matter since in either case an MR would have DHCP service whether
at home or away from home and the DUID would identify the MR so that it
will get the same information (same prefixes) whether at home or not.

No forwarding of IPv6 link-locals are needed for this.

> link-locals defined in rfc2529 (v6 over v4) and rfc2491 (v6 over NBMA).

Oops - I though RFC 2473 had the same type of language as IPv6 over PPP
(use an IEEE MAC if you have one otherwise pick a random interface ID type
stuff). Needs missing info to be fixed by IPv6 WG IMHO.

> like this is supposed to be made to work ok (I draw real physical

The way folks seem to be deploying IPv6 with prefix delegation
is that the border router runs both a DHCP server (for the local domain)
and a DHCP client (to request a prefix from the ISP).
Thus the DHCP clients in the local domain communicate with the BR=DHCPv6 server
and DHCP relays are only needed when there are routers inside the local domain.

  Erik

---

From: Alexandru Petrescu<[email-masked]>
Date: Fri, 04 Apr 2003 19:46:06 +0200

Erik, thank you for the clarifications...

Erik Nordmark wrote:
> It wouldn't matter since in either case an MR would have DHCP 
> service whether at home or away from home and the DUID would 
> identify the MR so that it will get the same information (same 
> prefixes) whether at home or not. No forwarding of IPv6 link-locals
>  are needed for this.

Aha, DUID, so the discovery phase has already happened, so probably no
need for ll's.

> Oops - I though RFC 2473 had the same type of language as IPv6 over
>  PPP (use an IEEE MAC if you have one otherwise pick a random 
> interface ID type stuff).

Ok, I must check that.

> The way folks seem to be deploying IPv6 with prefix delegation is 
> that the border router runs both a DHCP server (for the local 
> domain) and a DHCP client (to request a prefix from the ISP). Thus
> the DHCP clients in the local domain communicate with the BR=DHCPv
> server and DHCP relays are only needed when there are router
> inside the local domain.

Aha, that's correct.  The prefix delegation deployment types are
indeed like that (or rather).  If I have a network deployed at home
and suddenly ISP says it gives me prefix delegation, I would prefer
not to upgrade the existing CPE(?) but rather plug a new machine next
to it.  but that's debatable, sure.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 04 Apr 2003 19:47:34 +0200

Erik, regarding the previous mails on link-local addresses...

Overall, it is not clear to me how Mobile IPv6 treats ll-addressed
packets for a MH.

First, it allows for packets inside the tunnel to have ll addresses,
at least for DHCPv6 purposes (see citation [*] below)(rfc 2473 allows
that too).  Second, HA is allowed to intercept ll-addressed packets
for an MH (L==1).  Third, paradoxically to me, those intercepted
ll-addressed packets are not allowed to be tunneled to the MH (see [**]).

I suggest to allow those ll-addressed packets to be tunneled by HA
towards MH.

Pros: HA could be separated from DHCPv6 Agent (now Agent and HA must
       be co-located [***])
       HA could be separated from the routers running OSPF (if NEMO
       looks later at an MR with OSPF, this would be useful).

Cons: link-locals are no longer local, but that's ok, they're
       tunneled.
       I don't know whether this facilitates or not MLD.

This might have already been discussed by the Mobile IP WG, I don't
know.  Maybe there is already a strong argument behind HA being
forbidden to forward ll-addressed packets, I can live with it if it
exists.

What do you think?

PS:

How would DHCPv6 work if ll's were allowed to be tunneled, HA
separated from DHCP Agent
---------------------------------------------------------
The DHCPv6 discovery phase is made of 4 messages between host and
Server, and might include 1+ intermediary Relays.  The concern is
about messages between host and first Relay (Solicit and Advertise).
Those two messages use link-local addresses (src of Solicit is always
ll, dst of Solicit is mc, src of Advertise relayed by Relay is
presumably ll, dst of it is ll).

Assume host is at home and talks to Relay in order to obtain a  global
address.  Everything happens fine.

Assume there is a HA next to Relay (but not in the same machine).

Now assume host (MH) moves away from home, and reappears 10 days later
under a new AR.

In this case, the Solicit and Advertise messages will beencapsulated 
in the tunnel MH-HA.  After receiving the Solicit, the Relay will send 
the corresponding Advertise to MH's ll address (MH home ll address). 
Then HA would intercept it and tunnel it to the CoA.

draft 21 Mobile IPv6 citations
------------------------------
[*]
    "DHCPv6 messages sent to the mobile node with a link-local
     destination must be tunneled within the same tunnel header used
     for other packet flows."

[**] when talking about HA intercepting packets:
    "However, packets addressed to the mobile node's link-local address
     MUST NOT be tunneled to the mobile node.  Instead, such a packet
     MUST be discarded, and [...]"

[***]
    "Mobile nodes desiring to locate a DHCPv6 service may reverse
     tunnel standard DHCPv6 packets to the home agent.  Since these
     link-scope packets can not be forwarded onto the home network it
     is necessary for the home agent to either implement a DHCPv6 relay
     agent or a DHCPv6 server function itself."

Alex
GBU

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 7 Apr 2003 23:18:06 +0200 (CEST)

> Aha, DUID, so the discovery phase has already happened, so probably no

I can't parse. A client can form a DUID without any communication.
See draft-ietf-dhc-dhcpv6-28.txt secion 8.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 23 Apr 2003 18:50:25 +0200

Erik Nordmark wrote:
>> Aha, DUID, so the discovery phase has already happened, so probably
>>  no need for ll's.
> 
> 

Right.  I've made the assumption that you mentioned DUID to indicate
that server identifies host by DUID, and that ll addresses were not
involved.

But I was referring specifically to messages that have as source or
destination the ll addresses of the host.  It would be nice if those
messages were tunneled freely back and forth between MN and HA.

For example, the Mobile IPv6 spec says:

Later on it says:

    "Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel
     standard DHCPv6 packets to the home agent.  Since these link-scope
     packets can not be forwarded onto the home network it is necessary
     for the home agent to either implement a DHCPv6 relay agent or a
     DHCPv6 server function itself."

My reading of the spec is: "because Mobile IPv6 forbids HA to forward
ll-scoped packets to the home link, then co-locate the HA with a
relay". This is a bit wrong: Mobile IPv6 does not forbid to tunnel
ll-scoped packets from MN to HA, it forbids only the other way around.

I guess what I'm looking after is to have the HA separated from relay,
and to have the HA forward ll-scoped packets addressed to MN.

Or maybe I need to ask on the Mobile IP mailing list why the HA is
banned from forwarding the ll-scoped packets addressed to MN?  Or ask
why does the HA intercept the ll-scoped packets when L=1, what does the
HA do with those packets if it must drop them anyways?

Alex
GBU

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 25 Apr 2003 22:16:41 +0200 (CEST)

> HA do with those packets if it must drop them anyways?

I think I've already given my views on the above two points on the Nemo
list, but you are welcome to ask the MIP list.

  Erik

---

From: Ralph Droms <[email-masked]>
Date: Sun, 27 Apr 2003 15:03:44 -0400

At 06:50 PM 4/23/2003 +0200, Alexandru Petrescu wrote:
>>I can't parse. A client can form a DUID without any communication. See draft-ietf-dhc-dhcpv6-28.txt secion 8.
>

LL addresses and DUID are orthogonal ... the requesting router (MR)
and delegating router (HA) use LL unicast or multicast addresses
in all DHCP message exchanges.

The requesting router had a DUID that is invariant and is
used in all DHCP transactions.

>and to have the HA forward ll-scoped packets addressed to MN.

The only way to separate the HA from the relay is if the HA acts
as a bridge (or supports multi-link subnets) and forwards datagrams
with LL unicast and multicast addresses between the link shared 
by the HA and the relay and the tunnel to the MR.

---

From: Pekka =?iso-8859-1?Q?P��kk�nen?= <[email-masked]>
Date: Tue, 29 Apr 2003 12:04:27 +0200

>different link than the non-tunnel.

In order for DHCPv6 tunneling to be possible, there should be link-local 
addresses
configured on both the MR's and HA's tunnel-interface. These addresses are used
on the inner IPv6 header when sending DHCPv6 packets through the MR-HA tunnel.

So how to get the link-local addresses for the tunnel-interfaces. The 
link-local addresses
configured on the non-tunnel interface could be configured also on the 
tunnel-interface at
both MR and HA as mentioned by Erik. If those same link-local addresses are 
not used, then
I agree that there should a specification somewhere on how to configure 
link-local
addresses on the tunnel-interfaces.

Pekka