Subject: [nemo] FYI: Internal WG Review: Recharter of Mobility for IPv4 (mip4)

From: Thierry Ernst <[email-masked]>
Date: Tue, 20 Jun 2006 11:30:09 +0200

Relaying the same message on this list since we had related discussion last month. 
Thierry

Begin forwarded message:

Date: Thu, 15 Jun 2006 17:49:38 +0300
From: Jari Arkko <[email-masked]>
To: Mobile IPv6 Mailing List <[email-masked]>
Cc: Peter McCann <[email-masked]>, Henrik Levkowetz <[email-masked]>
Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4)

FYI -- MIP4 wants to recharter to include work on dual stack
Mobile IPv4 support (item 10 below). Given that MIP6 also
works on related issues I wanted to point you to this update.
Comments welcome.

--Jari

IESG Secretary wrote:

>A new charter for the Mobility for IPv4 (mip4) working group in the Internet
>Area of the IETF is being considered.  The draft charter is provided below for 
>your review and comment.
>
>Review time is one week.
>
>The IETF Secretariat
>
>+++
>
>Mobility for IPv4 (mip4)
>==========================
>
>Last Modified: 2006-06-13
>
>Current Status: Active Working Group
>
>Chair(s):
>Peter McCann <[email-masked]> 
>Henrik Levkowetz <[email-masked]> 
>
>Internet Area Director(s):
>Jari Arkko <[email-masked]> 
>Mark Townsley <[email-masked]> 
>
>Internet Area Advisor:
>Jari Arkko <[email-masked]> 
>
>Mailing Lists:
>General Discussion: [email-masked]
>To Subscribe: [email-masked]
>In Body: subscribe
>Archive: http://www.ietf.org/mail-archive/web/mip4/index.html
>
>Description of Working Group:
>
>IP mobility support for IPv4 nodes (hosts and routers) is specified in
>RFC3344. RFC 3344 mobility allows a node to continue using
>its "permanent" home address as it moves around the Internet. The
>Mobile IP protocols support transparency above the IP layer, including
>maintenance of active TCP connections and UDP port bindings.Besides
>the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal
>with concerns such as optimization, security, extensions, AAA support,
>and deployment issues.
>
>MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000
>networks). The scope of the deployment is on a fairly large scale and
>accordingly, the MIP4 WG will focus on deployment issues and on
>addressing known deficiencies and shortcomings in the protocol that
>have come up as a result of deployment experience. Specifically, the
>working group will complete the work items to facilitate interactions
>with AAA environments, interactions with enterprise environments when
>MIPv4 is used therein, and updating existing protocol specifications
>in accordance with deployment needs and advancing those protocols that
>are on the standards track.
>
>Work expected to be done by the MIP4 WG as proposed by this charter is
>as follows:
>
>1. MIPv4 has been a proposed standard for several years. It has been
>adopted by other standard development organizations and has been
>deployed commercially. One of the next steps for the WG is to advance
>the protocol to draft standard status. As part of advancing base
>Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised
>to reflect implementation experience
>
>2. Work items that are pending from the previous Mobile IP WG, which
>will be completed by the MIP4 WG, are:
>
>- completion of the MIB for the revised base Mobile IP
>specification (2006bis)
>
>- regional registration draft.
>
>3. The MIP4 WG will also complete the work on MIPv4 interactions
>in VPN scenarios. This work will involve identifying the requirements
>and a solution development for MIPv4 operation in the presence
>of IPsec VPNs.
>
>4. Additionally, a proposal has been made for how MOBIKE could work
>together with MIPv4. This proposal does not describe any new protocol,
>but formulates a best current practice for deploying MOBIKE together
>with MIPv4. The working group will adopt and complete this document.
>
>5. Some issues have been raised with respect to RFC3519. These will be
>identified and addressed as appropriate, through errata, revision
>of RFC 3519, and/or supplemental documents as needed.
>
>6. It has been proposed that the FMIP protocol, which has been
>standardised for MIPv6 in the MIPSHOP working group, should also be
>published as an experimental protocol for MIPv4. A draft for this
>exists. The working group will take up and carry this work forward
>to publication
>
>7. An extension to carry generic strings in the Registration Reply
>message has been proposed. The purpose is to supply supplemental
>human-readable information intended to the MN user. The working
>group will complete the specification and applicability statement of
>such an extension.
>
>8. RADIUS attributes for MIP4. A set of RADIUS attributes has
>been proposed for MIPv4.
>
>The working group will first produce a requirements specification,
>describing how the work differs from the requirements in RFC 2977
>and the functionality provided by RFC 4004 (the MIPv4 Diameter App).
>The reason why this first step is required is that RFC 3127 pretty
>clearly shows that full 2977 functionality can't be provided by even
>a considerably extended RADIUS, so we need to match the requirements
>to what can be done within RADIUS.
>
>Provided the requirements work finds approval with ADs and radext,
>the workgroup will complete the specification of MIPv4 RADIUS
>attributes, solicit feedback from the Radius Extensions WG, adjust,
>and submit this for publication.
>
>9. MIPv4 Extension for Configuration Options.
>
>Several drafts have proposed extensions to help improve configuration
>of MIPv4 clients. The latest proposal is for a general configuration
>option extension which could carry information such as e.g., DNS
>address and DHCP server address. The working group will take on
>and complete one proposal for a configuration option extension.
>
>10. Dual-stack Support
>
>There have been several proposals for how to enable an IPv6
>connection over a network that supports Mobile IPv4. The
>basic idea is to include an IPv6 address in the Mobile IPv4
>signaling messages. The working group will take on and complete
>one proposal for IPv6 over Mobile IPv4.
>
>Goals and Milestones:
>
>Done AAA Keys for MIPv4 to IESG
>Done MIPv4 VPN interaction problem statement to IESG
>Done Low latency handover to experimental
>Done Experimental MIPv4 message and extensions draft to IESG
>Done Dynamic Home Agent assignment protocol solution to IESG
>Done Revised MIPv4 Challenge/Response (3012bis) to IESG
>Done Regional registration document to IESG
>Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comment
>Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG
>May 2006 MIPv4 Mobike interaction (BCP) to the IESG
>May 2006 MIPv4 VPN interaction (BCP) to the IESG
>May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment
>Jun 2006 Revised MIPv4 specification to IESG for Draft Std.
>Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG
>Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IESG
>Sep 2006 FMIPv4 (Experimental) to the IESG
>Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG
>Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG
>Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG
>Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG
>  
>

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

-- 
Thierry ERNST, PhD
INRIA Rocquencourt Project-Team IMARA
+33 1 39 63 59 30 (office)

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Jun 2006 21:07:07 +0200

> Relaying the same message on this list since we had related 

Thierry, thanks for the forward.  What's the significance of that
discussion for this WG?

The MIP4 re-chartering in question is about the MIP4 WG taking on
developping MIPv4 extensions to support mobility for IPv6 as well.  MIP4
currently doesn't have that in its Charter.

A proposed solution is "DS-MIPv4", in draft-tsirtsis-v4v6-mipv4-01.txt.

For this WG, would it mean that it should advise the DS-MIPv4 work to
extend the IPv4 Prefix Table (described in the NEMOv4 base spec) to also
contain IPv6 prefixes?

If MIP4 WG DS-MIPv4 (or similar) work goes Standards Track with DS-MIP4,
would it suggest that NEMOv4 should go same way?

Alex

> Thierry
> 
> 
> Begin forwarded message:
> 
> Date: Thu, 15 Jun 2006 17:49:38 +0300 From: Jari Arkko 
> <[email-masked]> To: Mobile IPv6 Mailing List <[email-masked]>
>  Cc: Peter McCann <[email-masked]>, Henrik Levkowetz 
> <[email-masked]> Subject: [Mip6] FW: Internal WG Review: 
> Recharter of Mobility for IPv4 (mip4)
> 
> 
> 
> FYI -- MIP4 wants to recharter to include work on dual stack Mobile 
> IPv4 support (item 10 below). Given that MIP6 also works on related 
> issues I wanted to point you to this update. Comments welcome.
> 
> --Jari
> 
> IESG Secretary wrote:
> 
>> A new charter for the Mobility for IPv4 (mip4) working group in the
>>  Internet Area of the IETF is being considered.  The draft charter
>>  is provided below for your review and comment.
>> 
>> Review time is one week.
>> 
>> The IETF Secretariat
>> 
>> +++
>> 
>> Mobility for IPv4 (mip4) ==========================
>> 
>> Chair(s): Peter McCann <[email-masked]> Henrik Levkowetz 
>> <[email-masked]>
>> 
>> Internet Area Director(s): Jari Arkko <[email-masked]> Mark 
>> Townsley <[email-masked]>
>> 
>> Internet Area Advisor: Jari Arkko <[email-masked]>
>> 
>> Mailing Lists: General Discussion: [email-masked] To Subscribe: 
>> [email-masked] In Body: subscribe Archive: 
>> http://www.ietf.org/mail-archive/web/mip4/index.html
>> 
>> IP mobility support for IPv4 nodes (hosts and routers) is specified
>>  in RFC3344. RFC 3344 mobility allows a node to continue using its
>>  "permanent" home address as it moves around the Internet. The 
>> Mobile IP protocols support transparency above the IP layer, 
>> including maintenance of active TCP connections and UDP port 
>> bindings.Besides the basic Mobile IPv4 (MIPv4) protocols, several 
>> other drafts deal with concerns such as optimization, security, 
>> extensions, AAA support, and deployment issues.
>> 
>> MIPv4 is currently being deployed on a wide basis (e.g., in 
>> cdma2000 networks). The scope of the deployment is on a fairly 
>> large scale and accordingly, the MIP4 WG will focus on deployment 
>> issues and on addressing known deficiencies and shortcomings in the
>>  protocol that have come up as a result of deployment experience. 
>> Specifically, the working group will complete the work items to 
>> facilitate interactions with AAA environments, interactions with 
>> enterprise environments when MIPv4 is used therein, and updating 
>> existing protocol specifications in accordance with deployment 
>> needs and advancing those protocols that are on the standards 
>> track.
>> 
>> Work expected to be done by the MIP4 WG as proposed by this charter
>>  is as follows:
>> 
>> 1. MIPv4 has been a proposed standard for several years. It has 
>> been adopted by other standard development organizations and has 
>> been deployed commercially. One of the next steps for the WG is to
>>  advance the protocol to draft standard status. As part of
>> advancing base Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will
>> be revised to reflect implementation experience
>> 
>> 2. Work items that are pending from the previous Mobile IP WG, 
>> which will be completed by the MIP4 WG, are:
>> 
>> 3. The MIP4 WG will also complete the work on MIPv4 interactions in
>>  VPN scenarios. This work will involve identifying the requirements
>>  and a solution development for MIPv4 operation in the presence of
>>  IPsec VPNs.
>> 
>>  together with MIPv4. This proposal does not describe any new 
>> protocol, but formulates a best current practice for deploying 
>> MOBIKE together with MIPv4. The working group will adopt and 
>> complete this document.
>> 
>> 5. Some issues have been raised with respect to RFC3519. These will
>>  be identified and addressed as appropriate, through errata, 
>> revision of RFC 3519, and/or supplemental documents as needed.
>> 
>> group will complete the specification and applicability statement 
>> of such an extension.
>> 
>> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been
>>  proposed for MIPv4.
>> 
>> and the functionality provided by RFC 4004 (the MIPv4 Diameter 
>> App). The reason why this first step is required is that RFC 3127 
>> pretty clearly shows that full 2977 functionality can't be provided
>>  by even a considerably extended RADIUS, so we need to match the 
>> requirements to what can be done within RADIUS.
>> 
>> Several drafts have proposed extensions to help improve 
>> configuration of MIPv4 clients. The latest proposal is for a 
>> general configuration option extension which could carry 
>> information such as e.g., DNS address and DHCP server address. The
>>  working group will take on and complete one proposal for a 
>> configuration option extension.
>> 
>> 10. Dual-stack Support
>> 
>> connection over a network that supports Mobile IPv4. The basic idea
>>  is to include an IPv6 address in the Mobile IPv4 signaling 
>> messages. The working group will take on and complete one proposal
>>  for IPv6 over Mobile IPv4.
>> 
>> Goals and Milestones:
>> 
>> Done AAA Keys for MIPv4 to IESG Done MIPv4 VPN interaction problem
>>  statement to IESG Done Low latency handover to experimental Done 
>> Experimental MIPv4 message and extensions draft to IESG Done 
>> Dynamic Home Agent assignment protocol solution to IESG Done 
>> Revised MIPv4 Challenge/Response (3012bis) to IESG Done Regional 
>> registration document to IESG Mar 2006 MIPv4 RADIUS Extensions 
>> Requirements to RADEXT WG for comment Apr 2006 Revised rfc2794bis 
>> (NAI extension) (Draft Std.) to the IESG May 2006 MIPv4 Mobike 
>> interaction (BCP) to the IESG May 2006 MIPv4 VPN interaction (BCP)
>>  to the IESG May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG
>>  for comment Jun 2006 Revised MIPv4 specification to IESG for Draft
>>  Std. Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the
>> IESG Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.)
>> to the IESG Sep 2006 FMIPv4 (Experimental) to the IESG Sep 2006
>> MIPv4 RADIUS Extensions Requirements to the IESG Sep 2006 RADIUS 
>> Extensions for MIPv4 (Proposed Std.) to the IESG Dec 2006 Revised 
>> MIB for MIPv4 (Proposed Std.) to IESG Dec 2006 Dual-stack MIPv4 
>> (Proposed Std.) to IESG
>> 
>> 
> 
> 
> 
> _______________________________________________ Mip6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
> 
> 
>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 21 Jun 2006 05:21:44 -0700

Alex,

The DS-MIPv4 draft you point to in fact defines IPv6 prefix extensions
to MIPv4 so it includes support for v6 networks. Since we had to add an
extension to carry in IPv6 address, it made sense to make the extension
able to carry prefixes too. The draft also includes FA support and
dynamic prefix allocation and it has been written with NEMOv4 in mind so
the mechanics are very similar.

BTW, are you planning to submit an updated version of NEMOv4 draft? 

Regards
George

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Tuesday, June 20, 2006 3:07 PM
> To: Thierry Ernst
> Cc: ml-nemo
> Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobility for
> IPv4(mip4)
> 
> Thierry Ernst wrote:

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Jun 2006 15:19:00 +0200

Tsirtsis, George wrote:
> Alex,
> 
> The DS-MIPv4 draft you point to in fact defines IPv6 prefix 
> extensions to MIPv4 so it includes support for v6 networks. Since we 
> had to add an extension to carry in IPv6 address, it made sense to 
> make the extension able to carry prefixes too.

Makes sense.  How about adding IPv6 prefixes in the Prefix Table too
(not only in the MIP4 messaging and in the IPv4 Registration Table)?
The Prefix Table is an essential data structure for guaranteeing
security between MR and HA.

The NEMOv4 draft describes the Prefix Table for IPv4.  For NEMOv4 to
work over IPv6 networks it would need to have an extended Prefix Table
such that it contains the IPv6 prefixes too (not only IPv4 prefixes).

> BTW, are you planning to submit an updated version of NEMOv4 draft?

YEs, soon.

Alex

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 21 Jun 2006 06:43:45 -0700

Yes the draft already indicates that the DS-MIPv4 HA should maintain the
table of registered IPv6 prefixes. Is there something more you want me
to say? You seem to be making a distinction between the registration
table and the prefixes table which I am not sure I follow.

George

> Sent: Wednesday, June 21, 2006 9:19 AM
> To: Tsirtsis, George
> Cc: Thierry Ernst; ml-nemo

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Jun 2006 15:55:30 +0200

Tsirtsis, George wrote:
> Yes the draft already indicates that the DS-MIPv4 HA should maintain
> the table of registered IPv6 prefixes. Is there something more you
> want me to say? You seem to be making a distinction between the
> registration table and the prefixes table which I am not sure I
> follow.

The Prefix Table is a data structure different than the Registration
Table.  It is pre-configured at the Home Agent saying what Home Address
can use what Mobile Network Prefix.  It's only for security
verification.  It must be there.

Alex

> 
> George
> 
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Wednesday, June 21,
>> 2006 9:19 AM To: Tsirtsis, George Cc: Thierry Ernst; ml-nemo 
>> Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobility
>> for IPv4(mip4)
>> 
>> Tsirtsis, George wrote:
>>> Alex,
>>> 
>>> extensions to MIPv4 so it includes support for v6 networks. Since
>>> we had to add an extension to carry in IPv6 address, it made
>>> sense to make the extension able to carry prefixes too.
>> Makes sense.  How about adding IPv6 prefixes in the Prefix Table
>> too (not only in the MIP4 messaging and in the IPv4 Registration
>> Table)? The Prefix Table is an essential data structure for
>> guaranteeing security between MR and HA.
>> 
>> The NEMOv4 draft describes the Prefix Table for IPv4.  For NEMOv4
>> to work over IPv6 networks it would need to have an extended Prefix
>> Table such that it contains the IPv6 prefixes too (not only IPv4
>> prefixes).
>>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 21 Jun 2006 07:01:04 -0700

Oh you are talking about the implicit mode in NEMO. Yes, I could add
some words to that effect. Since DS-MIPv4 supports dynamic prefix
allocation, however, the HA simply has a pool of IPv6 addresses/prefixes
which it allocates as per DS-MIPv4. What you are asking for, however, is
also possible as a configuration option.

George 

> Sent: Wednesday, June 21, 2006 9:56 AM
> To: Tsirtsis, George
> Cc: ml-nemo; Thierry Ernst
> Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor
> IPv4(mip4)
> 
> Tsirtsis, George wrote:

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Jun 2006 16:23:23 +0200

Tsirtsis, George wrote:
> Oh you are talking about the implicit mode in NEMO.

Prefix Table is used for both explicit and implicit modes.

  Yes, I could add
> also possible as a configuration option.

Essential is for HA to verify that a HoA received in RegReq is allowed 
to use a certain MNP (be it in the RegRep, or allocated by the HA itself).

HAven't read ds-mipv4 allocation, but I guess it's done with DHCPv4 
PRefix Delegation.

Alex

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 21 Jun 2006 07:34:33 -0700

> Sent: Wednesday, June 21, 2006 10:23 AM
> To: Tsirtsis, George

MIPv4 has a number of ways that the HA can use to determine what HoA a
given MN is supposed to use. These include static configuration of HoA,
mapping of NAI to HoA, dynamic allocation of HoA. The IP address pools
used may also be locally configured or be retrieved by the HA on demand
based on DHCP or other mechanisms. I am not sure why we would want to
treat prefixes (v4 or v6) any different.

> HAven't read ds-mipv4 allocation, but I guess it's done with DHCPv4

Maybe you should read it before we have this discussion. Prefix
deligation is something that an HA can use to get an address pool. IMO
this is independent of how the HA allocates the addresses in the pool to
MNs.

George

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Jun 2006 16:44:50 +0200

Tsirtsis, George wrote:
>> 2006 10:23 AM To: Tsirtsis, George Cc: ml-nemo; Thierry Ernst 
>> Subject: Re: [nemo] FYI: Internal WG Review: Recharter of 
>> Mobilityfor IPv4(mip4)
>> 
>> Tsirtsis, George wrote:
>> Essential is for HA to verify that a HoA received in RegReq is 
>> allowed to use a certain MNP (be it in the RegRep, or allocated by 
>> the HA
> itself).
> 
> MIPv4 has a number of ways that the HA can use to determine what HoA 
> a given MN is supposed to use. These include static configuration of 
> HoA, mapping of NAI to HoA, dynamic allocation of HoA. The IP address
>  pools used may also be locally configured or be retrieved by the HA 
> on demand based on DHCP or other mechanisms. I am not sure why we 
> would want to treat prefixes (v4 or v6) any different.

Simply because the address is for a MH while the prefix is actually used
by the fixed hosts behind MR to make addresses.  So MR can guarantee for
the HoA it uses but can't guarantee for all addresses that can be
derived from a prefix.

I.e. if MR uses NAI for its home address can't use same NAI for the
addresses of LFNs behind it.  They should use their own NAIs.

> deligation is something that an HA can use to get an address pool. 
> IMO this is independent of how the HA allocates the addresses in the 
> pool to MNs.

The way HA allocates a prefix to MR should be the same whether MR is at
home or not.  When MR is at home (no MR-HA tunnel) most straighforward
way is DHCP prefix delegation, spec'ed and implemented.

I will read the draft.

NEMOv6 has ongoing DHCPv6 prefix delegation WG item between HA and MR.
I don't see why NEMOv4 would do it different than NEMOv6.

Alex

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 21 Jun 2006 07:52:16 -0700

> Sent: Wednesday, June 21, 2006 10:45 AM
> To: Tsirtsis, George

How do you know what the MR is using the addresses for? And why does it
matter to the HA?? When the HA agrees to redirect traffic for a prefix
to the MR it agrees to do so for all the addresses inside the prefix.
The signaling is between MR and HA and the HA has not clue and should
not care what is behind the MR.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Jun 2006 17:21:50 +0200

Tsirtsis, George wrote:
>>  2006 10:45 AM To: Tsirtsis, George Cc: ml-nemo; Thierry Ernst 
>>>> [mailto:[email-masked]] Sent: Wednesday, June
>>>>  21, 2006 10:23 AM To: Tsirtsis, George Cc: ml-nemo; Thierry 
>>>> Ernst Subject: Re: [nemo] FYI: Internal WG Review: Recharter of
>>>>  Mobilityfor IPv4(mip4)
>>>> 
>>>> Tsirtsis, George wrote:
>>>>> some words to that effect. Since DS-MIPv4 supports dynamic 
>>>>> prefix allocation, however, the HA simply has a pool of IPv6
>>> addresses/prefixes
>>>> allowed to use a certain MNP (be it in the RegRep, or allocated
>>>> by the HA
>>> itself).
>>> 
>>> MIPv4 has a number of ways that the HA can use to determine what
>>>  HoA a given MN is supposed to use. These include static 
>>> configuration of HoA, mapping of NAI to HoA, dynamic allocation 
>>> of HoA. The IP
> address
>>> pools used may also be locally configured or be retrieved by the
>>>  HA on demand based on DHCP or other mechanisms. I am not sure
>>> why we would want to treat prefixes (v4 or v6) any different.
>> Simply because the address is for a MH while the prefix is actually
>> 
>> 
>> 
> used
>> by the fixed hosts behind MR to make addresses.  So MR can 
>> guarantee
> for
> How do you know what the MR is using the addresses for?

That's the danger, with routers mobile and HA giving prefixes to them
there should be some security.

> And why does it matter to the HA?? When the HA agrees to redirect 
> traffic for a prefix to the MR it agrees to do so for all the 
> addresses inside the prefix. The signaling is between MR and HA and 
> the HA has not clue and should not care what is behind the MR.

MR gives access to an MH whose HA is different than MR's.  MH uses a CoA
from the MR's HA.  In case MH does troubles with that CoA, MR's HA
should be responsible for that, not the MR (which is mobile and more
difficult to find physically).

Anyways, there was a debate between DHCPv6-PD-based prefix allocation
and MIP6-based prefix allocation.  Currently only one is a WG item.
Maybe both should be.

Alex