Subject: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt

From: Ole Troan <[email-masked]>
Date: Wed, 26 Mar 2003 21:35:30 +0000

Pekka, Juhani,

what is the motivation for crafting your own MIPv6 specific PD
mechanism versus using e.g DHCPv6 PD? why not just specify how DHCPv6
PD could be used in a nemo environment?

cheers,
Ole

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> 	Title		: Mobile Network Prefix Delegation extension for Mobile 
>                           IPv6
> 	Author(s)	: P. Paakkonen, J. Latvakoski
> 	Filename	: draft-paakkonen-nemo-prefix-delegation-00.txt
> 	Pages		: 0
> 	Date		: 2003-3-25
> 	
> This draft proposes a dynamic Mobile Network Prefix (MNP) delegation 
> extension for Mobile IPv6 protocol to enable MNP delegation for 
> mobile networks. A MNP is an IPv6 prefix used in a mobile network.
> The extension supports dynamic delegation, return, refreshing and 
> updating operations related to MNP delegation operations between a 
> Mobile Router (MR) of a mobile network and the MR's Home Agent (HA).
> This extension is proposed, because there is a lack for a dynamic MNP 
> delegation protocol related to mobile networks, and currently MNPs have 
> to be assigned statically to enable mobile networking.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-paakkonen-nemo-prefix-delegation-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 2.  ( ) message/external-body  ( ) message/external-body

---

From: Pekka =?iso-8859-1?Q?P��kk�nen?= <[email-masked]>
Date: Thu, 27 Mar 2003 09:47:48 +0200

Hello Ole,

Using DHCPv6 prefix extensions might be one solution for MNP delegation.
But it is not clear to me at all how DHCPv6 can be used in a NEMO environment.
If a MR wants to execute MNP delegation operations with some entity in its 
home
network, when MR is away from home, DHCP relay agents must be used in a
foreign domain, because DHCPv6 uses link-local addressing, right? How are 
these
relay agents configured to direct prefix delegation messages to the right 
entity (for example MR's
HA) in MR's home network? If you have a view of how DHCPv6 prefix 
extensions can be
used (maybe depicted with some message flows), please explain.

If those MIPv6 extensions are used, then no relay agents would be needed in 
a foreign domain
(at least for MNP delegation).

Pekka

At 21:35 26.3.2003 +0000, Ole Troan wrote:
> >       "FILE 
> /internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt".
> >

---

From: Henrik Petander <[email-masked]>
Date: Thu, 27 Mar 2003 11:32:08 +0200

Hi Pekka,

Have you read the approach of the mipv6 spec on using dhcpv6 between MN 
and HA?

Dhcpv6 could be run between the HA and MN over the tunnel "link". HA and 
MN would use the logical tunnel interfaces' link local addresses. The 
same approach could be used also for NEMO, if MR runs also mobile ipv6. 
(To make this transparent to the dhcpv6 daemon, the tunnel needs to be 
visible as an interface in HA and MN.)

Regards,

Henrik Petander

Pekka =?iso-8859-1?Q?Pääkkönen?= wrote:

> If a MR wants to execute MNP delegation operations with some entity in
> its home
> foreign domain, because DHCPv6 uses link-local addressing, right? How
> are these
> relay agents configured to direct prefix delegation messages to the
> right entity (for example MR's
> If those MIPv6 extensions are used, then no relay agents would be needed
> in a foreign domain

---

From: Pekka =?iso-8859-1?Q?Pääkkönen?= <[email-masked]>
Date: Thu, 27 Mar 2003 12:28:37 +0200

Hi  Henrik,

If you refer to the section 10.4.4 of the MIPv6 spec, no, this is new to me.
So with this approach DHCPv6 relay functionality of a foreign network would 
not be needed,
when delegating MNPs from the home network?
The MR would tunnel its link-local DHCPv6 messages to its HA and DHCPv6 
server (HA)
would tunnel link-local messages to the MR .

There is still one problem on my mind.  In section 10.4.2 of MIPv6 spec it 
is defined that
"However, packets addressed to the mobile node's link-local address MUST 
NOT be tunneled to the mobile node. ".
But DHCPv6 with tunneling would require to tunnel DHCPv6 messages to the 
link-local address
of the MR. Does the definition in the spec mean that packets addressed to 
the link-local address of the
MR coming from a node other than the HA MUST not be tunneled to the MR, and 
those coming from
the HA MAY be tunneled to the MR? This would require filtering of the IP 
traffic at the HA based on
the source link-local address of the packet?

Pekka

At 11:32 27.3.2003 +0200, Henrik Petander wrote:
>MN would use the logical tunnel interfaces' link local addresses. The same 
>approach could be used also for NEMO, if MR runs also mobile ipv6. (To 
>make this transparent to the dhcpv6 daemon, the tunnel needs to be visible 
>as an interface in HA and MN.)
>
>Regards,
>
>Henrik Petander
>

---

From: Alexandru Petrescu<[email-masked]>
Date: Thu, 27 Mar 2003 11:43:21 +0100

Ole Troan wrote:
> mechanism versus using e.g DHCPv6 PD? why not just specify how 
> DHCPv6 PD could be used in a nemo environment?

Hi Ole, I'm inclined to believe we should look into using PD of DHCPv6
that way.

 From the PD DHCPv6 draft:

    "For example, the requesting router might assign a subnet
     from a delegated prefix to one of its interfaces, and begin
     sending router advertisements for the prefix on that link."

Is it possible for an MR (that got a prefix delegated from its HA) to
start acting as a DHCPv6 server itself for the LFN's in the mobile
network?

Alex

---

From: Alexandru Petrescu<[email-masked]>
Date: Thu, 27 Mar 2003 12:09:05 +0100

Hi Henrik,

Henrik Petander wrote:
> Dhcpv6 could be run between the HA and MN over the tunnel "link". 
> HA and MN would use the logical tunnel interfaces' link local 
> addresses. The same approach could be used also for NEMO, if MR 
> runs also mobile ipv6. (To make this transparent to the dhcpv6 
> daemon, the tunnel needs to be visible as an interface in HA and 
> MN.)

I agree that MR and the Mobile Node as defined by Mobile IPv6 should
use the same mechanism for DHCPv6.

I would add that, if MN uses DHCPv6 towards its HA, it would do so
both when it is away from home, and when it is at home, right?  In
that case,

> (To make this transparent to the dhcpv6 daemon, the tunnel needs to
>  be visible as an interface in HA and MN.)

I wonder if this is still transparent to the dhcpv6 cliend daemon
running on the MR (or MN).

I mean, when MN is away from home, it runs dhcpv6 client daemon over
the link designated by the tunnel interface.  However, when the MN is
at home, it will supposedly run the dhcpv6 client daemon directly over
a true interface link (say eth0).

So, my question was if the transparency aspect you mention above can 
be kept when MN is at home?  Can I do that?

Alex

---

From: Alexandru Petrescu<[email-masked]>
Date: Thu, 27 Mar 2003 12:00:17 +0100

Pekka =?iso-8859-1?Q?Pääkkönen?= wrote:
> Hello Ole,
> 
> Using DHCPv6 prefix extensions might be one solution for MNP 
> delegation. But it is not clear to me at all how DHCPv6 can be used
>  in a NEMO environment. If a MR wants to execute MNP delegation 
> operations with some entity in its home network, when MR is away 
> from home, DHCP relay agents must be used in a foreign domain, 
> because DHCPv6 uses link-local addressing, right?

Indeed MR must use link-local addressing, and this should be tunnelled
back to HA, not necessarily use relay agents in the foreign domain.

> If those MIPv6 extensions are used, then no relay agents would be 
> needed in a foreign domain (at least for MNP delegation).

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.

The link-local addressing issue comes mainly from the fact that Mobile
IPv6 bans the use of a Home Address as a link-local address.  A Home
Address can be either global or site-local (until recently).  Today it
could only be global, but not link-local.

It would be nice to have a homogeneous type of solution for all these
link-local addressing issues; and that would be to allow Home
Addresses as link-local addresses by the base Mobile IPv6 spec.

Otherwise, the other solutions that will eventually be developped is:
-new Mobile IPv6 messages and message types for PD.
-new Mobile IPv6 routing protocol messages.
-new Mobile IPv6 MLD messages.
-new RA and RS messages (as already done in fact by Mobile Prefix
  Sol/Adv).
-basically all that is link-local messaging will have new Mobile IPv6
  messages.

What do you think?

Alex

---

From: Ole Troan <[email-masked]>
Date: Thu, 27 Mar 2003 18:21:35 +0000

Alex,

> start acting as a DHCPv6 server itself for the LFN's in the mobile

sure. most typically by 'proxying' the stateless DHCP options across,
but you could very well do DHCP address assignment downstream also,
where the address pool is acquired via DHCP PD upstream.

cheers,
Ole

---

From: Henrik Petander <[email-masked]>
Date: Fri, 28 Mar 2003 11:34:22 +0200

> also uses link-local addressing.

The issue is not only with addressing, but also with the hop limit of 255.

 > -basically all that is link-local messaging will have new Mobile IPv6

IMHO it would be better to use link local addressing on the tunnel link
to allow running of existing link local protocols between HA and MR than
to reinvent non-mobile protocols as mipv6 / nemo extensions. Movement
between home and foreign links makes the first option more complex, 
though, but it is still only an implementation issue.

Henrik

---

From: Alexandru Petrescu<[email-masked]>
Date: Fri, 28 Mar 2003 20:30:15 +0100

Henrik Petander 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
> 
> 

Hi Henrik, what hop limit 255 issue do you see more exactly?

Is it related to nesting?

Or is it related to sending link-local packets across the tunnel?

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 31 Mar 2003 20:21:46 +0200 (CEST)

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

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

  Erik