Subject: [MEXT] Re: [nemo] Prefix Delegation documents

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Nov 2007 17:36:02 +0100

[NEMO topic Cc'ed on MEXT and not NEMO - hoping to correspond ok]

Romain KUNTZ wrote:
> Hi Alex,
> 
> On 2007/10/01, at 23:34, Alexandru Petrescu wrote:
>> Behcet Sarikaya wrote:
>>> I agree with Alex. DHAAD extension proposed in NEMO DHCP PD draft
>>>  is I think a stretch and may probably be not needed.
>> 
>> Err?  Sorry, I'm happy you agree with me, but I think the NEMO DHCP
>>  PD draft doesn't propose DHAAD extensions...(?)
> 
> And I agree with Behcet that this may not be useful, as the MIP6 
> bootstrapping work does not rely on DHAAD to assign HA addresses.

I see it differently.  I see it as the MIP6 bootstrapping work _should_
rely on DHAAD to assign the HA address.

(I've always wondered how could the MIP6 bootstrapping work simply
  ignore the existence of DHAAD.)

> draft-ietf-nemo-dhcpv6-pd-02 adds a new D flag to DHAAD in section 
> 3.5.

Right... just read it.

I think DHCPv6PD for NEMO uses DHAAD extensions (D bit) to obtain the
address of the DHCPv6PD Server HA (the Delegating Router DR).

I think this is a possible means to learn the DR address.

And another one is to multicast the DHCPv6 Solicit over the MR-HA tunnel
interface and for the receiving HA to multicast it further on the home
link and only the right DR will reply to it.  I think this can work too
and it may involve less modifications on software (no message extension).

What do others think - will this work?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

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

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 19 Nov 2007 12:04:11 +0100

Hi Alex,

> ignore the existence of DHAAD.)

DHAAD relies on the fact that the home prefix is known whereas MIP6  
bootstrapping does not.
Using DHAAD means first retrieving the home prefix by a to-be-defined  
way then using DHAAD, where a DNS lookup or SRV query is a more  
efficient and already existing protocol.

Regards,
-- 
Romain KUNTZ
[email-masked]
Louis Pasteur University - Networks and Protocols Team

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Nov 2007 12:22:45 +0100

> DHAAD relies on the fact that the home prefix is known whereas MIP6 

But Romain, the MN always has to have some pre-configured information 
before being able to acquire the HA address and HoA.

If MIP6 Bootstrapping pre-configures a NAI, or maybe a FQDN of the home 
domain - don't you think one can easily say that "MIP6 bootstrapping 
relies on the fact that the NAI or the FQDN is known whereas DHAAD does 
not" - and thus make it look as an inconvenient?

> efficient and already existing protocol.

But don't you think the same can be said about the FQDN?  How does MN 
retrieve its FQDN?

Alex

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 19 Nov 2007 14:50:31 +0100

On 2007/11/19, at 12:22, Alexandru Petrescu wrote:
> But Romain, the MN always has to have some pre-configured  
> information before being able to acquire the HA address and HoA.
>
> If MIP6 Bootstrapping pre-configures a NAI, or maybe a FQDN of the  
> home domain - don't you think one can easily say that "MIP6  
> bootstrapping relies on the fact that the NAI or the FQDN is known  
> whereas DHAAD does not" - and thus make it look as an inconvenient?

But from a deployment point of view, having a statically configured  
FQDN or just the domain name of the mobility operator is better than  
an IPv6 prefix, no?

>> Using DHAAD means first retrieving the home prefix by a to-be- 
>> defined way then using DHAAD, where a DNS lookup or SRV query is a  
>> more efficient and already existing protocol.
>
> But don't you think the same can be said about the FQDN?  How does  
> MN retrieve its FQDN?

I guess the FQDN or domain name would be given to the user when it  
subscribes to the service. Of course you may argue that the same could  
apply with the IPv6 home prefix, but I think the DNS and DNS SRV is  
more adapted to deployments precisely because the user is not  
provisioned with an address.

romain

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Nov 2007 15:56:05 +0100

Romain KUNTZ wrote:
>>>> I see it differently.  I see it as the MIP6 bootstrapping work 
>>>> _should_ rely on DHAAD to assign the HA address.
>>>> 
>>>> (I've always wondered how could the MIP6 bootstrapping work 
>>>> simply ignore the existence of DHAAD.)
>>> DHAAD relies on the fact that the home prefix is known whereas 
>>> MIP6 bootstrapping does not.
>> 

YEs, let's think from a deployment standpoint.

Why do you think pre-configuring a FQDN of the domain is better than the
IPv6 prefix of the home link?

Is it because the operator may take advantage of DNS and inserting a
different IP prefix for same FQDN in the DNS when it changed the
addresses?  But this does not cover the case when the operator changes
its FQDN names but keeps wants to keep the same addresses.

Or else - why do you think pre-configured FQDN is better from a
deployment point of view?

>>> Using DHAAD means first retrieving the home prefix by a 
>>> to-be-defined way then using DHAAD, where a DNS lookup or SRV 
>>> query is a more efficient and already existing protocol.
>> 
> subscribes to the service. Of course you may argue that the same 
> could apply with the IPv6 home prefix, but I think the DNS and DNS 
> SRV is more adapted to deployments precisely because the user is not 

You say so because you assume that the operator will always keep a
stable name and may sometime change its addresses if it wants to.

But I think that there are operators that change names and want to keep
their addresses.  Orange from FT is one example probably familiar.

And this latter case can not be accustomed if MIPv6 Bootstrapping
pre-configures the FQDN in the MN.  It can be accommodated if MIPv6
Bootstrapping pre-configures the home prefix.

I also think that it's the addresses that are the rare ressources not
the FQDNs.  Once one gets a block of addresses one is highly interested
in keeping them regardless of the changes in one's employer's name.
This has many reasons rooted in deployments, the difficulty in
renumbering being one of them.

Alex
PS: besides, there may be a mixture method relying on both FQDN+DNS and
     prefix+DHAAD - thus helping many more types of deployments, why not.

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 19 Nov 2007 19:02:03 +0100

On 2007/11/19, at 15:56, Alexandru Petrescu wrote:
>> FQDN or just the domain name of the mobility operator is better  
>> than an IPv6 prefix, no?
>

I do not speak only about FQDN, but also and mostly about Domain Name  
+ DNS SRV. With that, the client of the service only needs to know an  
usually stable domain name (ok, FT switched to orange for some of  
their services, but such operation is usually done with a huge  
advertisement campaign), and then the HA (hence the HA address) can be  
decided according to the location of the MN, the type of service it  
needs (we can imagine extending the SRV request to differentiate mip6,  
nemo or mcoa services) etc.

>>>> defined way then using DHAAD, where a DNS lookup or SRV query is  
>>>> a more efficient and already existing protocol.
>> SRV is more adapted to deployments precisely because the user is  
>> not provisioned with an address.
>

This is not a question of being able to renumber the home network, but  
being able to give to the MN the more suitable HA address.

> Bootstrapping pre-configures the home prefix.

Maybe this could help to have some operator point of view on this list?

>    prefix+DHAAD - thus helping many more types of deployments, why  

Yes, if there is a strong need for 2 solutions though I'd Ideally  
prefer one unique solution.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 20 Nov 2007 07:31:40 +0100

I'd say that one does not preclude the other. We could use DNS to get
the anycast address and leave the dynamics of load balancing to the
DHAAD process. 

Pascal
>-----Original Message-----
>From: Romain KUNTZ [mailto:[email-masked]]
>Sent: Monday, November 19, 2007 2:51 PM
>To: Alexandru Petrescu
>Cc: [email-masked]
>Subject: [MEXT] Re: [nemo] Prefix Delegation documents
>

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 20 Nov 2007 08:42:14 +0100

Hi Pascal,
Question on WG documents for prefix delegation. There are two of them:
1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, 2007)
2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006)
Are we still working on both solutions?
This work is relevant to AUTOCONF WG, as some want to work on PD.
And AUTOCONF shall verify existing specifications for being reused in a
MANET environment.
Teco.

> -----Oorspronkelijk bericht-----
> Van: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Verzonden: dinsdag 20 november 2007 7:32
> Aan: Romain KUNTZ; Alexandru Petrescu
> CC: [email-masked]
> Onderwerp: RE: [MEXT] Re: [nemo] Prefix Delegation documents
>

---

From: Romain KUNTZ <[email-masked]>
Date: Tue, 20 Nov 2007 11:51:19 +0100

Hi Pascal,

> the anycast address and leave the dynamics of load balancing to the

Ok, this might be useful to specify that in the MIP6 bootstrapping  
document.
But Alex's point was more about provisioning statically the MN with an  
IPv6 prefix, and not a domain name or FQDN.

romain

>> could

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 12:36:03 +0100

> the anycast address and leave the dynamics of load balancing to the

I agree.

If an operator pre-configures the DNS name of the home link on the MN 
then the MN could resolve it into the anycast address and run DHAAD from 
there.  If same operator pre-configures the home prefix then the MN will 
add the anycast extension to that prefix and run DHAAD from there too.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 12:37:50 +0100

> IPv6 prefix, and not a domain name or FQDN.

Yes - more like to leave open the choice of what an operator or human 
user wants to pre-configure on her/his MN: home prefix, DNS name of the 
home link, NAI, MAC address - a set of possibilities.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 12:40:51 +0100

Romain KUNTZ wrote:
> I do not speak only about FQDN, but also and mostly about Domain Name + 
> DNS SRV. With that, the client of the service only needs to know an 
> usually stable domain name (ok, FT switched to orange for some of their 
> services, but such operation is usually done with a huge advertisement 
> campaign), and then the HA (hence the HA address) can be decided 
> according to the location of the MN, the type of service it needs (we 
> can imagine extending the SRV request to differentiate mip6, nemo or 
> mcoa services) etc.

Yes, but when an operator changes the server HA what's easier and 
quicker means to update the MN: change HAs SRV entry in DNS or rely on 
DHAAD and periodic MPD the MN does?

>>>>> to-be-defined way then using DHAAD, where a DNS lookup or SRV query 
>>>>> is a more efficient and already existing protocol.

Sounds as a good requirement.

Another one would be to more efficiently and quickly update the MNs 
about a change in the home network.

Alex

> Yes, if there is a strong need for 2 solutions though I'd Ideally prefer 
> one unique solution.
>

---

From: Romain KUNTZ <[email-masked]>
Date: Tue, 20 Nov 2007 15:45:53 +0100

On 2007/11/20, at 12:40, Alexandru Petrescu wrote:
>> I do not speak only about FQDN, but also and mostly about Domain  
>> Name + DNS SRV. With that, the client of the service only needs to  
>> know an usually stable domain name (ok, FT switched to orange for  
>> some of their services, but such operation is usually done with a  
>> huge advertisement campaign), and then the HA (hence the HA  
>> address) can be decided according to the location of the MN, the  
>> type of service it needs (we can imagine extending the SRV request  
>> to differentiate mip6, nemo or mcoa services) etc.
>
> quicker means to update the MN: change HAs SRV entry in DNS or rely  
> on DHAAD and periodic MPD the MN does?

What do you mean by changing the server HA? changing the HA address? I  
don't really understand what would be the motivation for that, but I  
don't think an operator would change an HA address without any  
transition period. So changing the HA SRV entry in DNS is not really a  
problem.

BTW what does MDP would do in that case? If I understand your  
thoughts, the Home Link prefix is not supposed to change over the time.

>>>>>> defined way then using DHAAD, where a DNS lookup or SRV query  
>>>>> But don't you think the same can be said about the FQDN?  How  
>>>>> does MN retrieve its FQDN?
>>>> I guess the FQDN or domain name would be given to the user when  
>>>> it subscribes to the service. Of course you may argue that the  
>>>> same could apply with the IPv6 home prefix, but I think the DNS  
>>>> and DNS SRV is more adapted to deployments precisely because the  
>>>> user is not provisioned with an address.
>>>
>> This is not a question of being able to renumber the home network,  
>> but being able to give to the MN the more suitable HA address.
>

What are the changes you refer to? HA failure? In that case local HA- 
HA can do the job. I agree DHAAD can also help, but to achieve this we  
do not need to have the home link IPv6 prefix statically provisionned  
on the MN. In that case I'd prefer Pascal's proposal (ie retrieving  
the anycast address using DNS at the bootstrapping, and not provision  
statically the MN with that address).

romain

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 16:01:26 +0100

Romain KUNTZ wrote:
>>> Name + DNS SRV. With that, the client of the service only needs 
>>> to know an usually stable domain name (ok, FT switched to orange 
>>> for some of their services, but such operation is usually done 
>>> with a huge advertisement campaign), and then the HA (hence the 
>>> HA address) can be decided according to the location of the MN, 
>>> the type of service it needs (we can imagine extending the SRV 
>>> request to differentiate mip6, nemo or mcoa services) etc.
>> 
> What do you mean by changing the server HA? changing the HA address?

Yes.

> I don't really understand what would be the motivation for that, but 
> I don't think an operator would change an HA address without any 
> transition period. So changing the HA SRV entry in DNS is not really 
> a problem.

Well DNS propagation can take in the order of hours.

> thoughts, the Home Link prefix is not supposed to change over the 

Yes, MPD just in case.  In case one wants to reuse MPD to obtain the
most up to date prefix from the home link (before configuring the Home
Address), maybe the home link is about to be renumbered.  This was
designed with the same transitioning period in mind you mention about DNS.

>>>>>>> to-be-defined way then using DHAAD, where a DNS lookup or
>>>>>>>  SRV query is a more efficient and already existing 
>>>>>>> protocol.
>>>>>> But don't you think the same can be said about the FQDN? 
>>>>>> How does MN retrieve its FQDN?
>>>>> I guess the FQDN or domain name would be given to the user 
>>>>> when it subscribes to the service. Of course you may argue 
>>>>> that the same could apply with the IPv6 home prefix, but I 
>>>>> think the DNS and DNS SRV is more adapted to deployments 
>>>>> precisely because the user is not provisioned with an 
>>>>> address.
>>>> 
>>>> You say so because you assume that the operator will always 
>>>> keep a stable name and may sometime change its addresses if it 
>>>> wants to.
>>> This is not a question of being able to renumber the home 
>>> network, but being able to give to the MN the more suitable HA 
>>> address.
>> 
> What are the changes you refer to? HA failure? In that case local 
> HA-HA can do the job.

:-) err... local HA-HA... new messages.

Let's talk about a requirement that says minimal MIP6 implementation
extension :-)

> I agree DHAAD can also help, but to achieve this we do not need to
> have the home link IPv6 prefix statically provisionned on the MN. In
> that case I'd prefer Pascal's proposal (ie retrieving the anycast
> address using DNS at the bootstrapping, and not provision statically
> the MN with that address).

Sounds as a good possibility to which I'd agree.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 20 Nov 2007 10:45:23 -0800

> Are we still working on both solutions?

We have a sort of stalemate on this. I believe Jari (AD) would prefer
one solution in this space. I think the earlier decision by the NEMO
WG was to standardize both solutions. Not sure what the consensus is
right now.

IMO, we should standardize one ASAP. Without a prefix delegation
mechanism the only possible solution now is to pre-configure the
mobile network prefix on the mobile router. This is not sufficient.

Vijay

---

From: Sebastian Thalanany <[email-masked]>
Date: Tue, 20 Nov 2007 14:01:52 -0600

Hi, Pascal,
                      Yes, I agree. The configuration options to use DNS 
for an anycast address resolution should be an operator choice.

                       Thanks.
Regards,
   Sebastian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 21 Nov 2007 15:38:02 +0100

Hi Vijay

My proposal to break the tie is this:

- move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it
documents a way to use DHCP-PD but does not need new exchanges. Last I
checked, some components were still missing but Ralph knows better.

- focus on draft-ietf-nemo-prefix-delegation-02.txt for standard track.
The draft is agnostic to the delegation mechanism in the backend and
does not have dependencies. It proposes an integrated mechanism that
fits the general MIP6 / NEMO approach and formats.

What do you think?

Pascal

>From: Vijay Devarapalli [mailto:[email-masked]]
>Sent: Tuesday, November 20, 2007 7:45 PM
>To: Teco Boot
>Cc: Pascal Thubert (pthubert); [email-masked]
>Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents
>
>Teco Boot wrote:
>> Hi Pascal,

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Nov 2007 18:32:59 +0100

Pascal Thubert (pthubert) wrote:
>  documents a way to use DHCP-PD but does not need new exchanges.

But as Romain pointed out, DHCP-PD as specified in this draft extends
DHAAD by adding a new D flag.  If we want to avoid the use of the new D 
flag then we should (probably) say in the DHCP-NEMO-PD draft how that 
DHCPv6 Solicit is sent through the MR-HA tunnel (or not through tunnel) 
and then relayed by the HA on the home link (or the HA is the DHCPv6 
Server).

I think even if we move it to the Informational track then we still need
to improve some stuff in it according to implementation.  Or just let it 
float... I don't know.

> Last I checked, some components were still missing but Ralph knows 
> better.
> 
> - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard 
> track. The draft is agnostic to the delegation mechanism in the 
> backend and does not have dependencies.

But it extends MIP6, right?  (adds flags in messages).

> It proposes an integrated mechanism that fits the general MIP6 / NEMO
> approach and formats.
> 
> What do you think?

I think we should not extend MIP6 to do prefix allocation.  BEcause:

-I think addressing autoconfiguration mechanisms DHCP and others are
  already there for us to reuse and enhance eventually, no need to extend
  MIP6.
-what happens when MIPv6 allocates a prefix and PMIPv6 allocates one
  as well, but in a different way? (currently PMIPv6 doesn't seem to use
  NEMO-MIP6-PD flags neither does NEMO-MIP6-PD use PMIPv6 way of putting
  0 to mean request prefix).  Are the MIP6 and PMIP6 means to allocate
  prefixes equivalent?
-what happens when we want the prefix delegated to the MR to be
  accompanied by a delegation of responsibility of the DNS reverse
  resolution as well?  Can we reuse DHCP-DNS interactions (e.g. DNS
  update RFC2136)?  Or should we design a new MIP6-DNS interaction?

That's simply opinion.  I'm not sure about other criteria that came to 
give the suggestion you made.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 21 Nov 2007 10:57:19 -0800

> fits the general MIP6 / NEMO approach and formats.

I am fine with this approach.

For draft-ietf-nemo-prefix-delegation-02.txt, I would like to
simplify the mechanism a bit, by removing the Mobile Network
Prefix Confirm option. Just use the Mobile Network Prefix
option for the home agent to send the prefix to the mobile
router. I actually don't understand the need for the Mobile
Network Prefix Confirm option.

Vijay

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 22 Nov 2007 08:18:59 +0100

Thanks for the clarifications.

I wanted to know, as Prefix Delegation is being worked on in Autoconf also.
If Autoconf comes up with a third solution, it could be difficult to manage
in environments with equipment is both Mobile Router (NEMO) and MANET Router
(Autoconf). Are others also studying this overlap in functionality?

Maybe there are some issues with PD and DSMIPv6. Has anyone looked at this?

I suggest to keep the PD discussion in MEXT.

Teco.

> Van: Vijay Devarapalli [mailto:[email-masked]]
> Verzonden: woensdag 21 november 2007 19:57
> Aan: Pascal Thubert (pthubert)
> CC: Teco Boot; [email-masked]
> Onderwerp: Re: [MEXT] Prefix Delegation documents
> 
> track.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Nov 2007 14:56:53 +0100

Teco Boot wrote:
 > I wanted to know, as Prefix Delegation is being worked on in Autoconf
 > also. If Autoconf comes up with a third solution, it could be
 > difficult to manage in environments with equipment is both Mobile
 > Router (NEMO) and MANET Router (Autoconf). Are others also studying
 > this overlap in functionality?
 >

DS-MIPv6... I don't think it allocates prefixes in any way.  I think
DS-MIPv6 assumes that the underlying MIP6 implementation could allocate
prefixes.  Ie I take a MIP6 implementation, I enhance it with
NEMOv6-MIP6-PD messages and then I enhance it further with DS-MIPv6 
extensions.

IPv6-IPv4... "Prefix Delegation" is somehow called "Subnet Allocation"
for IPv4 in the DHCP WG.  Status-wise the IPv4 "DHCP Subnet Allocation"
has less impact, it's Informational, than DHCPv6-PD StdsTrack.  However,
technically on paper it seems to have more advanced features than
DHCPv6-PD (I haven't checked "DHCP Subnet Allocation" implementation).

 > I suggest to keep the PD discussion in MEXT.

What is "Prefix Delegation"?  Is it DHCPv6-PD?  Is it MIP6-based Prefix
Delegation?  Is it PMIPv6-based prefix allocation?

I'd suggest for "Prefix Delegation" to mean "DHCPv6-PD" and only that,
but can't enforce it I know.  As such I think it can be discussed 
anywhere where people  need a mechanism to autoconfigure prefixes 
(instead of just addresses).

Alex

 >
 > Teco.
 >
 >> -----Oorspronkelijk bericht----- Van: Vijay Devarapalli
 >> [mailto:[email-masked]] Verzonden: woensdag 21
 >> november 2007 19:57 Aan: Pascal Thubert (pthubert) CC: Teco Boot;
 >> [email-masked] Onderwerp: Re: [MEXT] Prefix Delegation documents
 >>
 >>> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as
 >>> it documents a way to use DHCP-PD but does not need new
 >>> exchanges. Last
 >> I
 >>> The draft is agnostic to the delegation mechanism in the backend
 >>> and does not have dependencies. It proposes an integrated
 >>> mechanism that fits the general MIP6 / NEMO approach and formats.
 >>>
 >>>
 >>> What do you think?
simplify the mechanism a bit, by removing the Mobile Network Prefix
 >> Confirm option. Just use the Mobile Network Prefix option for the
 >> home agent to send the prefix to the mobile router. I actually
 >> don't understand the need for the Mobile Network Prefix Confirm
 >> option.
 >>
 >> Vijay
 >>
 >>> Pascal
 >>>
 >>>> -----Original Message----- From: Vijay Devarapalli
 >>>> [mailto:[email-masked]] Sent: Tuesday,
 >>>> November 20, 2007 7:45 PM To: Teco Boot Cc: Pascal Thubert
 >>>> (pthubert); [email-masked] Subject: Re: [MEXT] Re: [nemo] Prefix
 >>>> Delegation documents
 >>>>
 >>>> Teco Boot wrote:
 >>>>> Hi Pascal, Question on WG documents for prefix delegation.
 >>>>> There are two of
 >>> them:
 >>>>>  2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006) Are
 >>>>> we still working on both solutions?
 >>>> one solution in this space. I think the earlier decision by the
 >>>> NEMO WG was to standardize both solutions. Not sure what the
 >>>> consensus is right now.
 >>>>
 >>>> IMO, we should standardize one ASAP. Without a prefix
 >>>> delegation mechanism the only possible solution now is to
 >>>> pre-configure the mobile network prefix on the mobile router.
 >>>> This is not sufficient.
 >>>>
 >>>> Vijay
 >
 >
 >
 > _______________________________________________ Autoconf mailing list
 >  [email-masked] https://www1.ietf.org/mailman/listinfo/autoconf
 >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Nov 2007 17:57:52 +0100

Hi Alex

My take is that similar DHAAD flags should be present in both drafts for
similar reasons; last I proposed it was rejected; I think that the
argument was that locating the HA should be a DNS issue anyway. From the
discussion we had recently with Romain, I still think that DHAAD and DNS
can be complementary.

You have some good points on DNS. But at this time we address prefixes
not hosts. How the hosts on the MNP get names and publish those is an
interesting issue but out of scope at this time.

The fact that the HA uses NEMO extensions to pass the prefix to the MR
does not preclude the use of a DHCP-PD server in the back end. It's just
abstracting and simplifying that interaction. One problem with the
DHCP-PD draft is lifetime of the lease: should it die with the MR-HA
tunnel? The Nemo based draft is conscious of the volatility of the
tunnel and the HA proxies the PD process for the MR based on the MR
demands.

Pascal

>From: Alexandru Petrescu [mailto:[email-masked]]
>Sent: Wednesday, November 21, 2007 6:33 PM
>To: Pascal Thubert (pthubert)
>Cc: Vijay Devarapalli; Teco Boot; [email-masked]
>Subject: Re: [MEXT] Prefix Delegation documents
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Nov 2007 18:11:39 +0100

Pascal Thubert (pthubert) wrote:
> Hi Alex
> 
> My take is that similar DHAAD flags should be present in both drafts 
> for similar reasons; last I proposed it was rejected; I think that 
> the argument was that locating the HA should be a DNS issue anyway. 
> From the discussion we had recently with Romain, I still think that 
> DHAAD and DNS can be complementary.
> 
> You have some good points on DNS. But at this time we address 
> prefixes not hosts. How the hosts on the MNP get names and publish 
> those is an interesting issue but out of scope at this time.

How does CN reverse resolve the LFN's IPv6 address (for e.g. when it
receives mail from it, to avoid spam)?  I think MR or other DNS server
_in_ the moving network should ultimately be in charge for that
resolution (and not HA or some entities in the home net).

And that can only be achieved if the mechanism of prefix allocation is
tightly coupled with DNS.

Otherwise, if you make MIP6 to delegate the prefix to MR then you should
extend MIP6 to update the DNS server as well.  I'm not saying this
should be done, but that's the consequence, as I see it.

I understand people may want to do everything with MIP6 (PMIP6, DS-MIP6,
Monami6, NEMO, etc) but at some point there are some existing things
that could be reused too.

> The fact that the HA uses NEMO extensions to pass the prefix to the 
> MR does not preclude the use of a DHCP-PD server in the back end. 
> It's just abstracting and simplifying that interaction.

I'm wondering of the necessity of this (a NEMO-MIP6 extension to support
DHCPv6-PD).  I doubt that's needed, DHCPv6-PD would work all by itself,
I think.

> One problem with the DHCP-PD draft is lifetime of the lease: should 
> it die with the MR-HA tunnel? The Nemo based draft is conscious of 
> the volatility of the tunnel and the HA proxies the PD process for 
> the MR based on the MR demands.

Right problem leasetime I think.

I think if either MIP6-NEMO-PD extensions or DHCPv6-PD is used then in
any case the DHCPv6 binding lease at the DHCPv6 Server should not
expire, I don't want another moving network to be allocated the same
prefix, because I may connect my moving network to that other moving
network and addresses may collide.

I think overall it is important to stick to one mechanism for
dynamically allocating prefixes.

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Nov 2007 18:35:31 +0100

Hi Alex:

There are actually examples where a short time lease is just what's
needed. It's good for privacy and a number of other reasons like getting
a prefix that is topologically correct not-too-far.

One of those examples is that of a MR visiting a MANET and getting a
local prefix for activity within that MANET that is topologically
correct in the area (AUTOCONF) and from which the MR can form a CoA that
it can keep as it moves around. 

Using NEMO to get the prefix enables the mobility of the delegated
prefix in and out the MANET - using or not the MANET protocol while in
the MANET space - till the MR finds that the prefix is useless and
forgets about it all.

Pascal

>Sent: Thursday, November 22, 2007 6:12 PM

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Nov 2007 18:43:54 +0100

Hi Vijay

The reason for the new MNPC option is that the original option did not
convey additional stuff that's required here. In particular, the corID
avoids delegating multiple prefixes if a BAck is lost.

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     | Prefix Length |P|I|D|Reserved1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     CorID                     |   Reserved2   | Prefix type   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Valid Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                   Mobile Network Prefix                       +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

But it's just one more value for the Type anyway and we still have
plenty.

What do you think?

Pascal

>Sent: Wednesday, November 21, 2007 7:57 PM
>Cc: Teco Boot; [email-masked]
track.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Nov 2007 20:17:41 +0100

Salut Pascal,

Pascal Thubert (pthubert) wrote:
> needed. It's good for privacy and a number of other reasons like
> getting a prefix that is topologically correct not-too-far.

I can agree that that there are scenarios where short time leases of a
prefix allocated by DHCP to a Mobile Router make sense.  A user PAN is
an example.  (a larger entity as a ship doing on2ly 2-3 handovers during
a transatlantic cruise probably needs more lease time).

I wanted to say that there are also scenarios where prefixes allocated
to a moving network are longer term, and the MR-HA tunnel being down
shouldn't mean that that prefix is no longer used in that ship.

> correct in the area (AUTOCONF) and from which the MR can form a CoA
> that it can keep as it moves around.

Somehow yes, I agree with you Mobile Router visiting a MANET and getting
a 'local' prefix (but still 'global' topologically correct) from it it
will probably be short-lived.

> prefix in and out the MANET - using or not the MANET protocol while
> in the MANET space - till the MR finds that the prefix is useless and
>  forgets about it all.

In order for the MANET network to deliver prefixes to visitors, do you
think a MANET network is more likely to run a HA inside or a DHCPv6
Server?  (my Windows Mobile PDA runs DHCPv4 Server, to not name a
manufacturer).

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 22 Nov 2007 13:56:09 -0800

I don't believe it is necessary to extend DHAAD for NEMO prefix
delegation. The mobile router could assume that the home agent it
is bootstrapping does support a mechanism for assigning prefixes
for the mobile network. I don't think we have any home agents
deployed today that support mobile routers to worry about. :) So
it would be safe to assume that a home agent that supports mobile
routers also supports a mechanism to assign a mobile network
prefix.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 22 Nov 2007 14:00:15 -0800

> avoids delegating multiple prefixes if a BAck is lost.

?? Why would the HA allocate a new prefix every time the BU is
sent? When the mobile router requests for one or prefixes, the
home agent responds with one or more prefixes. From there on,
subsequent binding updates sent to refresh an existing binding
will not contain any more requests for prefixes.

If the Binding Ack is lost, the MN retransmits the BU. At that
time, the HA assumes the mobile router lost state for some
reason and is requesting for its prefixes again. Then the HA
would send the same set of prefixes that were allocated earlier
to the mobile router. No new prefixes.

I must be missing something.

Vijay

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 23 Nov 2007 09:10:43 +0100

> Verzonden: donderdag 22 november 2007 18:36
> Aan: Alexandru Petrescu
> CC: Vijay Devarapalli; Teco Boot; [email-masked]
> Onderwerp: RE: [MEXT] Prefix Delegation documents
> 
> Hi Alex:
> 
> getting

How can a HA know which prefixes are topologically correct in a MANET?
MR is on visiting link, do you assume there is a relation between HA and
this visiting link?

> the MANET space - till the MR finds that the prefix is useless and

I think the MR can notify the HA that the delegated prefix is no longer
being used and ownership is given back to HA.
We can use the same mechanism for short time leases (e.g. transient) and
long time leases (e.g. persistent). 

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Nov 2007 11:15:53 +0100

> How can a HA know which prefixes are topologically correct in a MANET?

A HA in the MANET network would know the prefixes topologically correct 
in MANET because it would be administratively configured with these 
prefix(es).  Or it could itself run DHCPv6-PD as a Requesting Router.

> MR is on visiting link, do you assume there is a relation between HA and

I may mean a HA _within_ the MANET network, which would delegate a 
prefix to a visiting Mobile Router such that Mobile Router re-configures 
all its "NEMO" network.

It becomes complicated to explain on both sides I believe :-)

> long time leases (e.g. persistent).

I think yes, I think DHCP has a means for a Client to negotiate with the 
Server about how long it's going to use that address.  MIP6 would need 
to develop that.

Alex

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 24 Nov 2007 17:00:23 +0100

Hi Alex,

El 22/11/2007, a las 18:11, Alexandru Petrescu escribió:

>> My take is that similar DHAAD flags should be present in both  
>> drafts for similar reasons; last I proposed it was rejected; I  
>> think that the argument was that locating the HA should be a DNS  
>> issue anyway. From the discussion we had recently with Romain, I  
>> still think that DHAAD and DNS can be complementary.

why do you say that?
i mean, consider the case of the personal mobile router, do you think  
that my PDA should be my DNS server in charge of the reverse DNS for  
my mobil phone?

I mean, i may agree that in some cases, this can be a reasonable  
approach, but in general i would assume that the DNS servr is located  
in th home network (or even in the ISP of the home network)

> tightly coupled with DNS.

right, but it also needs to be a tight mechanims between the address  
autoconfiguration mechanism and the DNS update, since at the end of  
the day, you don't need to update the prefix in the DNS but the  
actual addresses that have been configured, right?

> should be done, but that's the consequence, as I see it.

I don't see why this is the case. You can have MIP to delegate the  
prefix, and then the MR announces the prefix in RA and then the MNN  
autoconfigures the prefix and then it should then updat the DNS, as  
any other node that has auto-configured an address

> that could be reused too.

with that, i fully agree

>> The fact that the HA uses NEMO extensions to pass the prefix to  
>> the MR does not preclude the use of a DHCP-PD server in the back  
>> end. It's just abstracting and simplifying that interaction.
>
>> One problem with the DHCP-PD draft is lifetime of the lease:  
>> should it die with the MR-HA tunnel? The Nemo based draft is  
>> conscious of the volatility of the tunnel and the HA proxies the  
>> PD process for the MR based on the MR demands.
>

again, i fully agree with you

Regards, marcelo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 24 Nov 2007 18:11:57 +0100

Hi Vijay:

Surely not allocating a prefix every time a BU is sent :) but for the
duration of a session, yes, we have use cases for that. 

Pascal

>Sent: Thursday, November 22, 2007 11:00 PM
>>        |                         Valid Lifetime
|
>>        |
|
>>        +
+
>>        |
|
>>        +                   Mobile Network Prefix
+
>>        |
|
>>        +
+
>>        |
|
>>>> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as
it
>>>> documents a way to use DHCP-PD but does not need new exchanges.
Last
>>>> The draft is agnostic to the delegation mechanism in the backend
and
>>>>> one solution in this space. I think the earlier decision by the
NEMO

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 24 Nov 2007 18:11:57 +0100

Hi Vijay:

Pascal

|
|
+
|
+
|
+
|
it
Last
and
NEMO

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 25 Nov 2007 13:47:26 +0100

Pascal Thubert (pthubert) wrote:
> Hi Vijay:
> 
> Surely not allocating a prefix every time a BU is sent :)

I agree with that: there should be no need for HA/entity to allocate a
prefix at each change of CoA - otherwise it's a complete mess.

Alex

> but for the duration of a session, yes, we have use cases for that.
> 
> Pascal
> 
>> [mailto:[email-masked]] Sent: Thursday, November
>> 22, 2007 11:00 PM To: Pascal Thubert (pthubert) Cc: Teco Boot;
>> [email-masked] Subject: Re: [MEXT] Prefix Delegation documents
>> 
>>> The reason for the new MNPC option is that the original option
>>> did
> not
>> sent? When the mobile router requests for one or prefixes, the home
>> agent responds with one or more prefixes. From there on, subsequent
>> binding updates sent to refresh an existing binding will not
>> contain any more requests for prefixes.
>> 
>> time, the HA assumes the mobile router lost state for some reason
>> and is requesting for its prefixes again. Then the HA would send
>> the same set of prefixes that were allocated earlier to the mobile
>> router. No new prefixes.
>> 
>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
> 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |     CorID                     |   Reserved2   | Prefix type
> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |                         Valid Lifetime
> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |
> |
>>> +
> +
>>> |
> |
>>> +                   Mobile Network Prefix
> +
>>> |
> |
>>> +
> +
>>> |
> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> But it's just one more value for the Type anyway and we still
>>> have plenty.
>>> 
>>> What do you think?
>>> 
>>> Pascal
>>> 
>>>> [mailto:[email-masked]] Sent: Wednesday,
>>>> November 21, 2007 7:57 PM To: Pascal Thubert (pthubert) Cc:
>>>> Teco Boot; [email-masked] Subject: Re: [MEXT] Prefix Delegation
>>>> documents
>>>> 
>>>>> does not have dependencies. It proposes an integrated
>>>>> mechanism
> that
>>>>>> (pthubert); [email-masked] Subject: Re: [MEXT] Re: [nemo]
>>>>>> Prefix Delegation documents
>>>>>> 
>>>>>> Teco Boot wrote:
>>>>>>> Hi Pascal, Question on WG documents for prefix
>>>>>>> delegation. There are two of
>>>>> them:
>>>>>>> 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21,
>>>>>>> 2007) 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28,
>>>>>>> 2006) Are we still working on both solutions?
>>>>>> We have a sort of stalemate on this. I believe Jari (AD)
>>>>>> would
>>> prefer
>>>>>> WG was to standardize both solutions. Not sure what the
>>>>>> consensus
> is
>>>>>> right now.
>>>>>> 
>>>>>> pre-configure the mobile network prefix on the mobile
>>>>>> router. This is not
> sufficient.
>>>>>> Vijay
> 
> _______________________________________________ MEXT mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mext
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 25 Nov 2007 14:36:07 +0100

Hi Marcelo,

marcelo bagnulo braun wrote:
> that my PDA should be my DNS server in charge of the reverse DNS for my 
> mobil phone?

Probably not my PDA, because too small (although my PDA runs a DHCP 
Server off-the-shelf, something surprising to me a few years ago), but a 
server in the moving network - yes.  If the prefix is allocated to the 
moving network then I'd want to have all control within that moving 
network, including DNS.

Remark, the MR shouldn't necessary be the DNS Server.

> approach, but in general i would assume that the DNS servr is located in 
> th home network (or even in the ISP of the home network)

I agree, there should be a DNS Server in the home network, but one in 
the moving network as well, especially with larger than a PAN moving 
network.

> autoconfiguration mechanism and the DNS update, since at the end of the 
> day, you don't need to update the prefix in the DNS but the actual 
> addresses that have been configured, right?

I agree, there should be a tight interaction between address 
autoconfiguration mechanism and DNS updating.

I want all DNS PTR requests about an address within a prefix allocated 
to that moving network to come to a DNS Server within that moving network.

(btw, with respect to the question above, I think Secure DNS UPDATE 
RFC3007 allows to update anything: IN AAAA RR's _and_ PTR RR's - sorry 
RR: Resource Record not Return Routability).  ISC DHCP Server 
implementation may allow a Client Mobile Router or a DHCP Server to 
update that entry).

> autoconfigures the prefix and then it should then updat the DNS, as any 
> other node that has auto-configured an address

How about PTR queries (a 'reverse' resolution)?  A CN makes a PTR DNS 
query about LFN's address (address being derived from the prefix you've 
put in RA).  Who answers that query?  The DNS Server in the home 
network?  Or a DNS Server in the moving network?  I'd like this latter. 
  I _think_ this can be achieved only if the DHCP Server updates the DNS 
Server with the IP address of the DNS Server in the movign network.

I may be wrong though... to be checked in implementation.

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 25 Nov 2007 20:58:05 +0100

Hi Teco:

I was referring to the model where a HA sits at the edge of a MANET and
delegates prefixes for visitors to the MANET. It acts as a secondary HA,
a bit like a HMIP MAP.

Pascal

>From: Teco Boot [mailto:[email-masked]]
>Sent: Friday, November 23, 2007 9:11 AM
>Cc: 'Vijay Devarapalli'; [email-masked]; 'Alexandru Petrescu'
>Subject: RE: [MEXT] Prefix Delegation documents
>
>
>
in
>> >> My take is that similar DHAAD flags should be present in both
drafts
>> >> The fact that the HA uses NEMO extensions to pass the prefix to
the
>> >> One problem with the DHCP-PD draft is lifetime of the lease:
should

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 25 Nov 2007 21:00:18 +0100

Hi Alex:

It will run what's necessary and standard :) delegation within NEMO
enables a tighter coupling and dependency management, and less messages.

Pascal

>Sent: Thursday, November 22, 2007 8:18 PM

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Nov 2007 10:29:38 +0100

> enables a tighter coupling and dependency management, and less

Less messages is something good to do.

In some cases if the DNS Server is within the moving network then
there'll be less DNS query messages exchanged over the MR-HA tunnel.
There'll be much reuse from the DNS cache.

Having the DNS Server in the moving network can be achieved either by
taking advantage of DHCP Client or Server updating the DNS, or by
extending MIP6 HA to update the DNS, or simply by the MR updating the
DNS with DNS UPDATE (the update should include the DNS Server's address
in the moving network.)  The existing open source software I'm aware
that could do this is part of DHCP Server, but anything else could do.

They have different requirements, technically different solutions.  But
it's good to reduce the number of messages.

Alex

> 
> Pascal
> 
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Thursday, November 22,
>> 2007 8:18 PM To: Pascal Thubert (pthubert) Cc: Vijay Devarapalli;
>>> There are actually examples where a short time lease is just
>>> what's needed. It's good for privacy and a number of other
>>> reasons like getting a prefix that is topologically correct
>>> not-too-far.
>> I can agree that that there are scenarios where short time leases
>> of a prefix allocated by DHCP to a Mobile Router make sense.  A
>> user PAN is an example.  (a larger entity as a ship doing on2ly 2-3
>> handovers
> during
>> I wanted to say that there are also scenarios where prefixes
>> allocated to a moving network are longer term, and the MR-HA tunnel
>> being down shouldn't mean that that prefix is no longer used in
>> that ship.
>> 
>>> One of those examples is that of a MR visiting a MANET and
>>> getting a local prefix for activity within that MANET that is
>>> topologically correct in the area (AUTOCONF) and from which the
>>> MR can form a CoA that it can keep as it moves around.
>> a 'local' prefix (but still 'global' topologically correct) from it
>> it will probably be short-lived.
>> 
>>> Using NEMO to get the prefix enables the mobility of the
>>> delegated prefix in and out the MANET - using or not the MANET
>>> protocol while in the MANET space - till the MR finds that the
>>> prefix is useless and forgets about it all.
>> In order for the MANET network to deliver prefixes to visitors, do
>> you think a MANET network is more likely to run a HA inside or a
>> DHCPv6 Server?  (my Windows Mobile PDA runs DHCPv4 Server, to not
>> name a manufacturer).
>> 
>> Alex
>> 
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit
>> http://www.messagelabs.com/email