Subject: [netlmm] Comments on draft-05

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 17 Sep 2007 20:47:04 +0430

Dear Sri

I went over the draft and it looks fine. Thanks for your trouble for
the improvement. Here are a few concerns.

1. Prefix lifetime.
As of RFC 2461, a default router advertises a prefix with Prefix
Information Option (PIO) in Router Advertisement message. PIO has two
prefix lifetime fields, 'Valid Lifetime' and 'Preferred Lifetime'.

However, I found no lifetime field in Home Network Prefix Option (with
which a MAG gets a Home Network Prefix from a LMA). So, when
advertising a Home Network Prefix to an MN, with which value does the
MAG configure the prefix lifetime?

2. Initial Binding Registration & Binding Re-Registration.

I think the terms 'Initial Binding Registration' & 'Binding Re-Registration'
are not clear enough.

The draft describes 'Initial Binding Registration' & 'Binding Re-Registration'
for LMA in 'Sec 5.3 Signaling Consideration' and
for MAG in 'Sec 6.9.1. Binding Registrations'.

   o  The local mobility anchor MUST use the identifier in the NAI
      option [RFC-4283] present in the Proxy Binding Update request for
      performing the Binding Cache entry existence test.  If the entry
      does not exist, the local mobility MUST consider this request as
      an initial binding registration request.

>From the above I assume that

Definition 1.
When a LMA receives a PBU from a MAG,
if the LMA has no Binding Cache entry for the MN-Identifer in the PBU,
this is Initial Binding Registration.

On the other hand,

When a LMA receive a PBU from a MAG,
if the LMA has a Binding Cache entry for the MN-Identifer in the PBU,
this is Binding Re-Registration,
even though the Binding Cache entry is associated with an another MAG

Am I right? If so, the above definition may not work with the MAG case
in Sec 6.9.1.

First, it's difficult to divide MAG operation into
'Initial Binding Registration' and 'Binding Re-Registraion'.

When sending a PBU to a LMA for a newly attached MN,
a MAG doesn't know
whether the LMA has a Binding Cache entry for the MN or not.

So the MAG has no way to know whether
it performs 'Initial Binding Registration' or 'Binding Re-Registration'

Moreover I got the impression that
the terms 'Initial Binding Registration' and 'Binding Re-Registraion'
mean different things for LMA (Sec 5.3) and MAG (Sec 6.9.1).

For MAG, we may define 'Initial Binding Registraion' and 'Binding
Re-Registraion'
differently using the MAG's Binding Update List as below.

Definition 2.
When a MAG sends a PBU for an MN,
if the MAG has no entry for the MN in its Binding Update List,
this is 'Initial Binding Registraion'.

On the other hand

When a MAG sends a PBU for an MN,
if the MAG has an entry for the MN in its Binding Update List,
this is 'Binding Re-Registraion'.

As you can see, Definition 1 and Definition 2 are not identical.
I am afraid that it may cause confusion to use the same terms
'Initial Binding Registration' & 'Binding Re-Registraion' in two
different meanings.

I'll write more about these in the in-line comments below.

In Sec 1.
An undefined term 'proxy mobility agent' were used a few times.
Does this mean 'MAG' or 'MAG + LMA'?

sub
This approach to supporting/ This approach to support

In Sec 2.2.
sub
with the additional required capabilities for/ with the additional
capabilities required for

In Sec 3.
sub
The local mobility/ The local mobility anchor

In Sec 5.3.

   o  The local mobility anchor MUST use the identifier in the NAI
      option [RFC-4283] present in the Proxy Binding Update request for
      performing the Binding Cache entry existence test.  If the entry
      does not exist, the local mobility MUST consider this request as
      an initial binding registration request.

After the above, I recommend to add the below.

    If the entry exists, the local mobility anchor MUST consider this
request as an Binding Re-Registration request

Also sub
local mobility/ local mobility anchor

In Binding Re-Registraion part,
I recommend to add a case for HNP Option with 0::/0 as below.

   o  If the Home Network Prefix option present in the Proxy Binding
      Update request has the value 0::/0 but there is a Binding Cache
   entry for the MN, the local mobility anchor MUST use the Home
Network Prefix associated with the entry and send a Proxy Binding
Acknowledgement message with the Home Network Prefix.

In Sec 6.6

sub
be able/ be able to

In Sec 6.9.1.

'Initial Binding Registraion' and 'Binding Re-Registraion' are not
clearly defined for MAG.

   Binding Re-Registration:

   o  For extending the lifetime of a currently existing binding at the
      local mobility, the mobile access gateway MUST send a Proxy
      Binding Update message to the local mobility anchor.

How can the MAG know that, for a newly attached MN,
there already exists a binding in an LMA?

    The prefix
      value in the Home Network Prefix option present in the request
      SHOULD be set to the currently registered home network prefix

Even if there exists a binding, the MAG may not know
the currently registered Home Network Prefix,
unless there exists an entry for the Binding Update List.
In that case, we'd better allow a Home Network Prefix Option with 0::/0 value.

In Sec 7.2.

                                      As long as the attached access
   network is in the scope of that Proxy Mobile IPv6 domain, the mobile
   node will always detect the same link, where it obtained its initial
   address configuration.  If the mobile node performs DHCP operation,
   it will always obtain the same address as before.

This may be wrong. Performing DHCP operation in PMIPv6 domain,
the MN will get the addresses with the same Home Network Prefix
but may not always get the same address.

I recommend to change the last part as

                          If the mobile node performs DHCP operation,
   it will always obtain an address with the same Home Network Prefix.

Thanks for your kind consideration.

Best Regards

JinHyeock

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 17 Sep 2007 19:33:54 -0700

Hi JinHyeock, 

> -----Original Message-----
> From: JinHyeock Choi [mailto:[email-masked]] 
> Sent: Monday, September 17, 2007 9:17 AM
> To: [email-masked]
> Subject: [netlmm] Comments on draft-05
> 
> Dear Sri
> 

The HNP is delated to the MAG and once the p2p link comes up,
the MAG needs to host this prefix on the link and advertise the
prefix. So, the considerations from 2461 apply. I thought about
this in the past and did not see a need to provide guidance on
the lifetime parameters. But, we can tie this to the accepted BU
lifetime or specify some optional config params in the profile.
But, its really about IPv6 prefix config on a link.

> I think the terms 'Initial Binding Registration' & 'Binding 

I see your point. 
What is initial registration for a MAG is a re-registration
for the LMA. I will try to differentiate and fix the title.

> Does this mean 'MAG' or 'MAG + LMA'?

This is not a term. Its the core concept of PMIP. There is an
entity that does proxy mip function and that we call it as a MAG.
I removed the term PMA from the draft, after your comment
some time back. But, I do not think, this line adds any ambiguity.

> This approach to supporting/ This approach to support

Ok

> capabilities required for

ok

> The local mobility/ The local mobility anchor

Ok.

> request as an Binding Re-Registration request

ok

> local mobility/ local mobility anchor

ok

> Acknowledgement message with the Home Network Prefix.

ok

> be able/ be able to

ok

> 'Initial Binding Registraion' and 'Binding Re-Registraion' are not

As I commented above, I will fix the titles and differentiate the
two cases.

> In that case, we'd better allow a Home Network Prefix Option 

I will clarify this to indicate that when there is BUL entry for
that MN, instead of saying, if there exists a binding on the LMA ...

> but may not always get the same address.

No. This is correct. The client identifier in the DHCP request will
remain the same. This is exactly as how, when your laptop does a dhcp
lease extension, gets the same address. The identifier of the client
is present in the request and the DHCP server would allocate the same
address as before. It wont consider this request as a request from a
different client.
 
> Thanks for your kind consideration.

Thanks for your good comments. I will make the changes.

Sri

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 18 Sep 2007 09:51:32 +0430

Sri

thanks for your kind and prompt reply. please see my in-line comments.

> But, its really about IPv6 prefix config on a link.

ok. I understand that a MAG is entitled to configure prefix lifetime
with its own discretion. Maybe we'd better explicitly write that down
in Sec 6.7. Home Network Emulation. How about adding the below at the
end of 6.7.?

When advertising the home network prefix,
the mobile access gateway can configure the prefix lifetime value
with its own discretion.
But an implementation can tie the prefix lifetime to the accepted PBU lifetime
or specify some optional configuration parameters in the profile.

> for the LMA. I will try to differentiate and fix the title.

ok. thanks.

> address as before. It wont consider this request as a request from a

If a DHCP relay agent puts a whole IPv6 address
in a DHCPv6 Request message as a hint to a DHCP server,
the DHCP can allocate the same address as before.

However,
1) the DHCP relay agent in a foreign network may not know
   the MN's existing IPv6 address (because HNP Option provides only HNP) and
2) it's written in the draft that
   the DHCP relay agent puts 'the mobile node's home network prefix' as below.

    6.11.  Interaction with DHCP Relay Agent

    When the mobile node sends a DHCPv6 Request message, the DHCP relay
    agent function on the access link will set the link-address field in
    the DHCPv6 message to the mobile node's home network prefix, so as to
    provide a prefix hint to the DHCP Server for the address pool
    selection.

Am I missing something? If so, kindly let me know.

Best Regards

JinHyeock

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 17 Sep 2007 22:39:04 -0700

Hi JinHyeock,

> Sent: Monday, September 17, 2007 10:22 PM
> To: Sri Gundavelli
> Cc: [email-masked]
> Subject: Re: [netlmm] Comments on draft-05
> 
> Sri
> 

Actually, lot of your initial comments made into the draft. Thanks
for some good comments.

> in Sec 6.7. Home Network Emulation. How about adding the below at the

I will try add some text around this. Will provide some guidance.

> Am I missing something? If so, kindly let me know.

The DHCP server keeps a binding between an address and a client id.
If there is a valid lease for a client, any subsequent request from
the client will still contain the same client id and the DHCP server
will attempt to issue the same address. 

Also, the request is comming from the MN and if its knows its earlier
address, it can request for the same. If it does not know its earlier
address, but if there exists a lease on the DHCP server for that
client, it will still end up with its earlier address, because the
client id is still the same. This is per 3315, standard behavior.

If you reboot your laptop today, you will still get the same address,
unless the pool size is overloaded or some special settings are active.
The server attempts to allocate an address, that the client is using
earlier. 

Thanks
Sri

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 18 Sep 2007 10:40:31 +0430

> client id is still the same. This is per 3315, standard behavior.

I am afraid that DHCP server may change.

>From the above, I see that the MN will get the same address
if it sends a DHCP request to the SAME DHCP server.

However, after moving to a different network,
the MN would send a DHCP request to a different DHCP server,
which won't have a binding for the MN.

Allow me an example.

Assume an MN is attached to MAG 1 and
allocated an address from DHCP server 1.
Then the MN moves to another network and
attaches itself to MAG2.
After related pmipv6 procedure,
the MN sends a DHCP request to
a different DHCP server 2.

How can we be sure that DHCP server 2
will always allocate the MN's existing address?

Also IMO, we don't need to ensure that DHCP server
always allocates the same address. PMIPv6 would work just fine even
when DHCP server would allocate the different addresses (with the same
HNP).

Best Regards

JinHyeock

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 17 Sep 2007 23:44:25 -0700

> Sent: Monday, September 17, 2007 11:11 PM
> To: Sri Gundavelli
> Cc: [email-masked]

It wont do the DHCP discover for lease extension. The request will be
unicasted as the client has the state.

> when DHCP server would allocate the different addresses (with the same

Ok. I'm fine stating that it will get an address from its HNP, that's
the key point. This is a normal access link and we dont have to specify
further details. 

Ok. Thanks for the comments.

Sri

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 18 Sep 2007 14:41:02 +0200

Hi JinHyeock, Sri,

> > Also IMO, we don't need to ensure that DHCP server always allocates 
> > the same address. PMIPv6 would work just fine even when DHCP server 
> > would allocate the different addresses (with the same HNP).
> > 
> 
> Ok. I'm fine stating that it will get an address from its 
> HNP, that's the key point. This is a normal access link and 
> we dont have to specify further details. 

IMO, if this is about lease extension, then the network should always return the same address and not a different one based on the same HNP. Otherwise there will be no IP session continuity thus defeating the purpose of the PMIP.

During the inital attachment to a PMIP domain, the network if free to return any address, based on any HNP. 

domagoj

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: 18. rujan 2007 08:44
> To: 'JinHyeock Choi'
> Cc: [email-masked]
> Subject: RE: [netlmm] Comments on draft-05
> 
> 
>  
> 
> It wont do the DHCP discover for lease extension. The request 
> will be unicasted as the client has the state.
> 
> 
> > From the above, I see that the MN will get the same address if it 
> > sends a DHCP request to the SAME DHCP server.
> > 
> > However, after moving to a different network, the MN would 
> send a DHCP 
> > request to a different DHCP server, which won't have a 
> binding for the 
> > MN.
> > 
> > Allow me an example.
> > 
> > Then the MN moves to another network and attaches itself to MAG2.
> > Also IMO, we don't need to ensure that DHCP server always allocates 
> > the same address. PMIPv6 would work just fine even when DHCP server 
> > would allocate the different addresses (with the same HNP).
> > 
> 
> Ok. I'm fine stating that it will get an address from its 
> HNP, that's the key point. This is a normal access link and 
> we dont have to specify further details. 
>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Sep 2007 16:09:25 +0200

Hi JinHyeock, Sri and Domagoj,

On Tuesday 18 September 2007, Premec, Domagoj wrote:
>
> IMO, if this is about lease extension, then the network should always
> return the same address and not a different one based on the same
> HNP. Otherwise there will be no IP session continuity thus defeating
> the purpose of the PMIP. 
>
> During the inital attachment to a PMIP 
> domain, the network if free to return any address, based on any HNP.

I agree completely with that statement of Domagoj. Thus, for the reasons 
JinHyeock explained well in his note copied below, I think that we 
should ensure that for a given MN, the DHCPv6 server remains the same. 
That would ensure the same address will be allocated by the DHCPv6 
server.

Since only one DHCPv6 server must handle address allocation for a MN 
attaching to different MAGs and access links, the following requirement 
we can derive one requirement on DHCPv6 deployments arise:

   - DHCPv6 relays must be deployed on each access link of the PMIPv6
     domain. Also, since the link between MAG and MN is point-to-point,
     that translates into a requirement for a DHCPv6 relay to be
     collocated with the MAG.

Noting that a DHCPv6 relays "places a global or site-scoped address with 
a prefix assigned to the link on which the client should be assigned an
address in the link-address field.  This address will be used by the
server to determine the link from which the client should be assigned
an address and other configuration information" [RFC3315], the following 
limitation arises:

   - the MAG/Relay has to know a global address with a prefix assigned
     to the link on which the client should be assigned an address. That
     means the MAG/Relay has to know the HNP for the MN before it
     (to derive the "global address with a prefix assigned to the link
     on which the client should be assigned an address") forward the
     DHCPv6 message.

Thus, DHCPv6 cannot be used to retrieve the HNP at first attachment. HNP 
must be obtained via other means such as PMIPv6 HNP option, or 
out-of-band (e.g. AAA).

Thoughts?

--julien

On Tuesday 18 September 2007, JinHyeock Choi wrote:
> > the client will still contain the same client id and the DHCP
> > server will attempt to issue the same address.
> >
> > Also, the request is comming from the MN and if its knows its
> > earlier address, it can request for the same. If it does not know
> > its earlier address, but if there exists a lease on the DHCP server
> > for that client, it will still end up with its earlier address,
> > because the client id is still the same. This is per 3315, standard
> > behavior.
>
> when DHCP server would allocate the different addresses (with the
> same HNP).
>
> Best Regards
>
> JinHyeock

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 18 Sep 2007 16:37:29 +0200

Hi Julien,

> Noting that a DHCPv6 relays "places a global or site-scoped 
> address with a prefix assigned to the link on which the 
> client should be assigned an address in the link-address 
> field.  This address will be used by the server to determine 
> the link from which the client should be assigned an address 
> and other configuration information" [RFC3315], the following 
> limitation arises:
> 
> Thus, DHCPv6 cannot be used to retrieve the HNP at first 
> attachment. HNP must be obtained via other means such as 
> PMIPv6 HNP option, or out-of-band (e.g. AAA).

In PMIP6, the choice for the allocation of a HNP is not related to a location (link) where the MS attached to the network. From that perspective, the link-address field does not seem to be useful for DHCP server. Maybe we could relax the requirement on DHCPv6 relays and allow them to relay a request without link-address field. DHCP server is free to allocate any HNP in response to such request. Would that work?

domagoj

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: 18. rujan 2007 16:09
> To: [email-masked]; Premec, Domagoj
> Cc: JinHyeock Choi; Sri Gundavelli
> Subject: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] 
> Comments on draft-05)
> 
> > return the same address and not a different one based on 
> the same HNP. 
> > Otherwise there will be no IP session continuity thus defeating the 
> > purpose of the PMIP.
> >
> > During the inital attachment to a PMIP domain, the network 
> if free to 
> > return any address, based on any HNP.
> 
> I agree completely with that statement of Domagoj. Thus, for 
> the reasons JinHyeock explained well in his note copied 
> below, I think that we should ensure that for a given MN, the 
> DHCPv6 server remains the same. 
> That would ensure the same address will be allocated by the 
> DHCPv6 server.
> 
> Since only one DHCPv6 server must handle address allocation 
> for a MN attaching to different MAGs and access links, the 
> following requirement we can derive one requirement on DHCPv6 
> deployments arise:
> 
> Noting that a DHCPv6 relays "places a global or site-scoped 
> address with a prefix assigned to the link on which the 
> client should be assigned an address in the link-address 
> field.  This address will be used by the server to determine 
> the link from which the client should be assigned an address 
> and other configuration information" [RFC3315], the following 
> limitation arises:
> 
> Thus, DHCPv6 cannot be used to retrieve the HNP at first 
> attachment. HNP must be obtained via other means such as 
> PMIPv6 HNP option, or out-of-band (e.g. AAA).
> 
> Thoughts?
> 
> --julien
>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Sep 2007 17:08:21 +0200

Hi Domagoj,

On Tuesday 18 September 2007, Premec, Domagoj wrote:
>
> On Tuesday 18 September 2007, Julien Laganier wrote:
>
> >    - the MAG/Relay has to know a global address with a prefix
> >      assigned to the link on which the client should be assigned an
> >      address. That means the MAG/Relay has to know the HNP for the
> >      MN before it (to derive the "global address with a prefix
> >      assigned to the link on which the client should be assigned an
> >      address") forward the DHCPv6 message.
> >
> In PMIP6, the choice for the allocation of a HNP is not related to a
> location (link) where the MS attached to the network. 

I can agree that the allocation of a HNP is not related to the 
*location* where the MS is attached to the network. 

ALthough a PMIPv6 domain contains many different access links, from the 
MN point of view the PMIPv6 service model is that of a single emulated 
home link which follows the MN, and on which a home network prefix is 
advertized.

I thus disagree that the allocation of HNP is not related to which home 
link the MS is attached to. There's a one-to-one correspondence between 
a home link and a HNP. More below...

> From that perspective, the link-address field does not seem to be
> useful for DHCP server.

I disagree with this statement. The link-address field is the only piece 
of information that can be used by the DHCPv6 server to determine the 
home link from which the client should be assigned an address and other 
configuration information. What other piece of information could be 
used otherwise?

> Maybe we could relax the requirement on DHCPv6 relays and allow them
> to relay a request without link-address field. 

That would be a change to the DHCP specification and should be avoided 
IMHO.

> DHCP server is free to allocate any HNP in response to such request.

Exactly what I would not like to happen: In case where the HNP is chosen 
by LMA or via an out-of-band protocol (e.g. AAA) or by LMA, the DHCP 
server should allocate addresses in that same HNP. 

Thus, in the absence of the link-address field, the above would require 
the DHCP server to be interfaced with either the LMA or AAA 
infrastructure.

Thoughts?

--julien

> > > IMO, if this is about lease extension, then the network
> >
> > should always
> >
> > > Otherwise there will be no IP session continuity thus defeating
> > > the purpose of the PMIP.
> > >
> >    - DHCPv6 relays must be deployed on each access link of the
> > PMIPv6 domain. Also, since the link between MAG and MN is
> > point-to-point,
> >    - the MAG/Relay has to know a global address with a prefix
> > assigned to the link on which the client should be assigned an
> > address. That
> >      (to derive the "global address with a prefix assigned to the
> > link on which the client should be assigned an address") forward
> > the DHCPv6 message.
> >
> > > > The DHCP server keeps a binding between an address and a
> >
> > client id.
> >
> > > > If there is a valid lease for a client, any subsequent
> >
> > request from
> >
> > > > the client will still contain the same client id and the
> >
> > DHCP server
> >
> > > > earlier address, it can request for the same. If it does not
> > > > know its earlier address, but if there exists a lease on the
> >
> > DHCP server
> >
> > > > because the client id is still the same. This is per
> >
> > 3315, standard
> >
> > > > behavior.
> > >
> > > Also IMO, we don't need to ensure that DHCP server always
> > > allocates the same address. PMIPv6 would work just fine even when
> > > DHCP server would allocate the different addresses (with the same
> > > HNP).
> > >
> > > Best Regards
> > >
> > > JinHyeock
>

---

From: "John.zhao" <[email-masked]>
Date: Wed, 19 Sep 2007 11:23:18 +0800

> configuration information. What other piece of information could be
[John.zhao] I'm not sure if I missed something. If I'm wrong, please
indicate kindly. If does the Client Identifier Option can also be used to
achieved this goal?

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 19 Sep 2007 14:38:03 +0300

Hi Domagoj,
 
> return the same address and not a different one based on the same HNP.

Unless dictated otherwise by the, for example, AAA. AAA can require the
access network to assign a particular HNP and HoA to the MN even for the
initial network entry.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 19 Sep 2007 14:48:23 +0300

Hi Julien,

>      that translates into a requirement for a DHCPv6 relay to be

There are alternative approaches. Different DHCP servers (e.g., ones
collocated with the MAGs) can be used as long as they can be
dynamically-provisioned with the MN configuration parameters, for example,
during network access authentication.

A general comment: We shall avoid such "system-level requirements" in our
protocol spec unless absolutely necessary.

Alper

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Sep 2007 14:12:03 +0200

Alper Yegin wrote:
> Hi Julien,
> 
>> Since only one DHCPv6 server must handle address allocation for a 
>> MN attaching to different MAGs and access links, the following 
>> requirement we can derive one requirement on DHCPv6 deployments 
>> arise:
>> 

I would agree.

However, DHCP Relays with point-to-point links is not something widely 
used, is it?  But I'd agree it can work.

> dynamically-provisioned with the MN configuration parameters, for 
> example, during network access authentication.

What's 'dynamically-provisioned'?  Is it a SDO-specific mechanism?  I
don't know how a deployer would like to deploy a DHCP Server in each MAG
without mentioning how these pools of addresses are dynamically provisioned.

Alex

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

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 19 Sep 2007 15:19:57 +0200

Alper,  

> From: Alper Yegin [mailto:[email-masked]] 
> Sent: 19. rujan 2007 13:38
> To: Premec, Domagoj; 'Sri Gundavelli'; 'JinHyeock Choi'
> Cc: [email-masked]
> Unless dictated otherwise by the, for example, AAA. AAA can 
> require the access network to assign a particular HNP and HoA 
> to the MN even for the initial network entry.

I agree. I also think this falls into category "network is free to assign any address based on any HNP", it is purely network's decision. You seem to be distinguishing access network from the (core?) network. OK, I can agree to that.

domagoj

> > > It wont do the DHCP discover for lease extension. The 
> request will 
> > > be unicasted as the client has the state.
> > >
> > >
> > > > Assume an MN is attached to MAG 1 and allocated an address from 
> > > > DHCP server 1.
> > > > How can we be sure that DHCP server 2 will always allocate the 
> > > > MN's existing address?
> > > >
> > > > DHCP server would allocate the different addresses 
> (with the same HNP).
> > > >
> > >
> > > Ok. I'm fine stating that it will get an address from its HNP, 
> > > that's the key point. This is a normal access link and we 
> dont have 
> > > to specify further details.
> > >

---

From: Julien Laganier <[email-masked]>
Date: Wed, 19 Sep 2007 15:29:03 +0200

> Hi Julien,

Hi Alper,

> > point-to-point, that translates into a requirement for a DHCPv6
> > relay to be collocated with the MAG.
>

If the DHCPv6 server changes after handover, that implies that the new 
DHCPv6 server will not reply to a DHCPv6 renew message sent by the MN 
since the renew was to be handled by the previous DHCPv6 server. The 
new DHCPv6 server will not reply either to the DHCPV6 rebind message 
sent by the MN unless there's a mechanism to share DHCPv6 client 
bindings amongst the different DHCP servers. 

AFAIK we do not have such a mechanism. Thus, it seems like we can't have 
different DHCPv6 servers handle a single MN.

Am I missing something?

> A general comment: We shall avoid such "system-level requirements" in
> our protocol spec unless absolutely necessary.

Agree.

--julien

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 19 Sep 2007 15:35:58 +0200

Alper,

> Different DHCP servers 
> (e.g., ones collocated with the MAGs) can be used as long as 
> they can be dynamically-provisioned with the MN configuration 
> parameters, for example, during network access authentication. 

I think in this case we should be more specific how the address renewal is supposed to work. The MN will remember the address of the first MAG as the address of the DHCP server. How is renewal message delivered: MN->current MAG->LMA->inital MAG/DHCP server? And the response, does it go through the LMA or not? Without specifying the exact behaviour, IMO this will work only in closed systems.

domagoj

> Sent: 19. rujan 2007 13:48
> To: 'Julien Laganier'; [email-masked]; Premec, Domagoj
> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: 
> [netlmm] Comments ondraft-05)
> 
> Hi Julien,
> 
> for a MN 
> > attaching to different MAGs and access links, the following 
> > requirement we can derive one requirement on DHCPv6 
> deployments arise:
> > 
> There are alternative approaches. Different DHCP servers 
> (e.g., ones collocated with the MAGs) can be used as long as 
> they can be dynamically-provisioned with the MN configuration 
> parameters, for example, during network access authentication.
> 
> A general comment: We shall avoid such "system-level 
> requirements" in our protocol spec unless absolutely necessary.
> 
> Alper
> 
> 
> > 
> > Noting that a DHCPv6 relays "places a global or site-scoped address 
> > with a prefix assigned to the link on which the client should be 
> > assigned an address in the link-address field.  This 
> address will be 
> > used by the server to determine the link from which the 
> client should 
> > be assigned an address and other configuration information" 
> [RFC3315], 
> > the following limitation arises:
> > 
> attachment. 
> > HNP must be obtained via other means such as PMIPv6 HNP option, or 
> > out-of-band (e.g. AAA).
> > 
> > Thoughts?
> > 
> > --julien
> > 
> > > > If there is a valid lease for a client, any subsequent request 
> > > > from the client will still contain the same client id 
> and the DHCP 
> > > > its earlier address, but if there exists a lease on the DHCP 
> > > > server for that client, it will still end up with its earlier 
> > > > address, because the client id is still the same. This is per 
> > > > 3315, standard behavior.
> > >
> > > However, after moving to a different network, the MN would send a 
> > > DHCP request to a different DHCP server, which won't have 
> a binding 
> > > for the MN.
> > >
> > > Allow me an example.
> > >
> > > Assume an MN is attached to MAG 1 and allocated an 
> address from DHCP 
> > > server 1.
> > > How can we be sure that DHCP server 2 will always 
> allocate the MN's 
> > > existing address?
> > >
> allocates

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 19 Sep 2007 17:48:09 +0300

> without mentioning how these pools of addresses are dynamically

It's typically done via AAA. For example, sending Framed-IP-Address via
RADIUS is for configuring that IP address via DHCP (or PPP).

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 19 Sep 2007 17:59:53 +0300

Julien,

> different DHCPv6 servers handle a single MN.

You mean "we haven't defined how to do that in IETF?" I agree.
But that does not mean it is not doable, especially outside the scope of
IETF. 

Alper

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Sep 2007 17:01:17 +0200

Alper Yegin wrote:
>>> There are alternative approaches. Different DHCP servers (e.g.,
>>> ones collocated with the MAGs) can be used as long as they can be
>>>  dynamically-provisioned with the MN configuration parameters,
>>> for example, during network access authentication.
>> What's 'dynamically-provisioned'?  Is it a SDO-specific mechanism?
>> I don't know how a deployer would like to deploy a DHCP Server in
>> each MAG without mentioning how these pools of addresses are
>> dynamically provisioned.
> 
> It's typically done via AAA. For example, sending Framed-IP-Address
> via RADIUS is for configuring that IP address via DHCP (or PPP).

Any deployed system today with wireless point-to-point links using
Framed-IP-Address via RADIUS gives that IP address to mobile with DHCP?
  I thought all are PPP.

I've framed my mind to think that if wireless access link is
point-to-point then it's PPP, and if it's shared medium wifi then it's
DHCP; never otherwise.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Wed, 19 Sep 2007 17:30:17 +0200

Alper,

On Wednesday 19 September 2007, Alper Yegin wrote:
> > If the DHCPv6 server changes after handover, that implies that the
> > new DHCPv6 server will not reply to a DHCPv6 renew message sent by
> > the MN since the renew was to be handled by the previous DHCPv6
> > server. The new DHCPv6 server will not reply either to the DHCPV6
> > rebind message sent by the MN unless there's a mechanism to share
> > DHCPv6 client bindings amongst the different DHCP servers.
> >
> > AFAIK we do not have such a mechanism. Thus, it seems like we can't
> > have different DHCPv6 servers handle a single MN.
>

Good.

> But that does not mean it is not doable, especially outside the scope
> of IETF.

Then shouldn't we add some guidance text to DHCPv6 deployers explaining 
that unless such out-of-scope mechanism is present some limitations are 
placed on DHCPv6 deployments: DHCPv6 relays have to be present at each 
MAG, and configured to forward DHCPv6 messages to the same group of 
DHCPv6 servers (and implicitly that the group of DHCPv6 servers should 
be reachable from every relay).

What do you think?

--julien

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 19 Sep 2007 16:20:35 -0400

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Wednesday, September 19, 2007 10:01 AM
> To: Alper Yegin
> Cc: [email-masked]; 'Julien Laganier'
> Subject: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO
> 
> Alper Yegin wrote:
[KC>] Nope...there are p2p wireless access links (3GPP, WiMAX) out there
where PPP is not used.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 20 Sep 2007 12:10:46 +0300

Julien,

> be reachable from every relay).

As long as we present such text as "informational", that's fine (no
MUST/SHOULD/etc.). And yes, that text is useful.

Alper

---

From: Julien Laganier <[email-masked]>
Date: Thu, 20 Sep 2007 13:17:51 +0200

Alex,

On Wednesday 19 September 2007, Alexandru Petrescu wrote:
> Framed-IP-Address via RADIUS gives that IP address to mobile with
> DHCP? I thought all are PPP. 

First of all, this question relates to system architecture. This list 
does not discuss specification of system architecture.

Second, but that is only peripheral to the point above, if all of our 
needs were satisfied with what we have *today*, we would not need to be 
here arguing about specification of *future* systems.

> point-to-point then it's PPP, and if it's shared medium wifi then
> it's DHCP; never otherwise.

Then unframe your mind :)

More seriously, it is irrelevant to this forum what your tastes and 
beliefs about system architecture are since this forum is not 
specifying any system architecture.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Sep 2007 14:14:31 +0200

> does not discuss specification of system architecture.

I'm trying to deduce from the various deployed system architectures how 
the DHCP Relay can come into picture.

You use the argument that we should use DHCP Relay on MAG because only 
one DHCP Server can allocate addresses.  To which Alper says that 
'pre-provisioning' can alleviate that restriction.

I'd like to use other arguments in favor of your suggestion, but I can't 
seem to find one.

If I wanted to stay in the SDO line of suggestion, I could very well say 
that a certain SDO _requires_ DHCP Relay on the access router, and a 
DHCP Proxy too.  But that doesn't make much sense to say, even less to 
frame one's mind around.  Because I'd like to see the DHCP Client 
running on a mobile's wman ptp link, before making claims about the 
future.  You seem to have already seen this?

> here arguing about specification of *future* systems.

Yes, but relying on the past to predict the future is also good.

(Do you remember when people claimed that 3G will use IPv6?  It's not
  long ago.  Now 3G is here and w/o IPv6, except some test deployments.)

> Then unframe your mind :)

I'd very much like to unframe half of my mind and play right now with a 
deployed mobile that uses DHCP on a ptp wireless access link.  To avoid 
risking to look ridiculous to the other half :-)

> specifying any system architecture.

I think once we request DHCP presence on a PMIP entity we talk architecture.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Thu, 20 Sep 2007 14:39:40 +0200

Alex,

On Thursday 20 September 2007, Alexandru Petrescu wrote:
> [...]
> You use the argument that we should use DHCP Relay on MAG because
> only one DHCP Server can allocate addresses.  To which Alper says
> that 'pre-provisioning' can alleviate that restriction.

Just to make sure: *if* DHCP is used in a PMIP domain then client 
bindings for a given MN have to be dealt with by a single DHCP server, 
and thus a DHCP relay connecting to that server has to be present on 
each MAG (since the access link is pt-to-pt).

Alper and I then agreed that it can be made to work with multiple DHCP 
servers dealing with client bindings for a single MN provided it exists 
an out-of-scope mechanism allows to distribute client bindings amongst 
many DHCP servers.

We also agreed that the spec could give some guidance to DHCP deployers 
in PMIP domain: *if* DHCP is used in a PMIP domain, unless an 
out-of-scope mechanism allows to distribute client bindings amongst 
many DHCP servers, then client bindings for a given MN have to be dealt 
with by a single DHCP server, and thus a DHCP relay connecting to that 
server has to be present on each MAG.

>[...]

We do not "request DHCP presence on a PMIP entity", as you put it. We 
are discussing, and maybe documenting what limitations on DHCP 
deployments exists *when* DHCP is deployed. This is not architecture.

--julien
> architecture.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Sep 2007 15:05:42 +0200

Julien Laganier wrote:
>> [...] You use the argument that we should use DHCP Relay on MAG 
>> because only one DHCP Server can allocate addresses.  To which 
>> Alper says that 'pre-provisioning' can alleviate that restriction.
> 

I get this part.

> each MAG (since the access link is pt-to-pt).

I don't get this part.  What ptp has to do with it?  Maybe I'm missing
something...

> Alper and I then agreed that it can be made to work with multiple 
> DHCP servers dealing with client bindings for a single MN provided it
>  exists an out-of-scope mechanism allows to distribute client
> bindings amongst many DHCP servers.

What do you mean by 'out-of-scope'?  The basic dhcp rfc allows for
multiple servers, then there's rfc3074 for Load Balancing among Servers
and a Failover protocol in a (expired) draft-ietf-dhc-failover-12.txt.
All implemented in the ISC's DHCP implementation, and deployed at the
IETF meetings; it runs in my lab too.  Why 'out-of-scope'?
'Out-of-scope' for whom?

> We also agreed that the spec could give some guidance to DHCP 
> deployers in PMIP domain: *if* DHCP is used in a PMIP domain, unless 
> an

Are you sure here you don't give an advice out in the dark?  Who are the
DHCP deployers for ptp wireless access for mobile?  I don't know any, do
you?  Or are you giving an advice to an SDO and not a deployer?

> many DHCP servers,

Why out of scope?

> then client bindings for a given MN have to be dealt with by a single
>  DHCP server,

Right.

> each MAG.

I don't get this part.  One can put a DHCP Proxy on a MAG and a DHCP 
Relay on another MAG and the central DHCP Server will still be able to 
maintain addresses ok, provided the DHCP Proxy is allocated a pool of 
addresses by the DHCP Server 'by an out-of-scope mechanism'.

>> [...] I think once we request DHCP presence on a PMIP entity we 
>> talk architecture.
> 

Ok, I think it is good to document it perhaps.

Alex

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 20 Sep 2007 10:14:05 -0400

Question for clarification:

Is DHCPv6 used for IPv6 address config for a host? If yes, could you
please point out which DHCPv6 option is used for that? 

AFAIK, DHCPv6 is used for prefix delegation. Is prefix delegation ==
IPv6 address config?

BR,
Kuntal

> Sent: Thursday, September 20, 2007 4:11 AM
> To: 'Julien Laganier'
> Cc: [email-masked]
> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]
> Commentsondraft-05)
> 
> Julien,
> 
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 20 Sep 2007 07:29:10 -0700

> From: Chowdhury, Kuntal [mailto:[email-masked]] 
> Sent: Thursday, September 20, 2007 7:14 AM
> To: Alper Yegin; Julien Laganier
> Cc: [email-masked]
> [netlmm]Commentsondraft-05)
> 

RFC-3315.
 
> AFAIK, DHCPv6 is used for prefix delegation. Is prefix delegation ==

No. Its the IPv4 DHCP equivalent.

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 20 Sep 2007 10:28:27 -0400

> Sent: Thursday, September 20, 2007 9:29 AM
> To: Chowdhury, Kuntal; 'Alper Yegin'; 'Julien Laganier'
> Cc: [email-masked]
[KC>] I know that for sure. But, could you point out which option is
used to configure IPv6 address in the host?

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Sep 2007 16:37:08 +0200

>> please point out which DHCPv6 option is used for that? 

Like at least for example how is the DHCP CONFIRM message used?  How or 
is REBIND used or not?

Do they happen before or after the P-BU/P-BAck?  Not clear in the 
pictures of draft-05.

> No. Its the IPv4 DHCP equivalent.

I agree it should, except that in details at least the message exchanges 
are different.

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 20 Sep 2007 07:38:06 -0700

> Sent: Thursday, September 20, 2007 7:28 AM
> To: Sri Gundavelli; Alper Yegin; Julien Laganier
> Cc: [email-masked]

I think its the IA Address Option.

Sri

> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 20 Sep 2007 10:48:58 -0400

> Sent: Thursday, September 20, 2007 9:38 AM
[KC>] I also thought so, until someone told me that DHCPv6 is primarily
used for prefix delegation and NOT address assignment to a host. If you
read IA definition carefully, it actually talks about assigning a group
of addresses to an interface on a host.

Anyway, the point is that SLAAC is the predominant IPv6 address config
mechanism. It is widely adopted and implemented. Use of DHCPv6 for
address configuration is not that popular and I am not sure whether it
is even used anywhere or not.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Sep 2007 17:02:59 +0200

Chowdhury, Kuntal wrote:
[...]
> is even used anywhere or not.

Kuntal, thanks, but I'd be careful with this message.

Because talking deployment of DHCPv6 vs SLAAC is not that 
straightforward, in the case of shared links.

Indeed SLAAC is first thing seen by anybody moving from IPv4 to IPv6; 
but DHCPv6 clients exist in Windows Vista (to not name it) and even 
DHCPv4 _Servers_ exist in Windows Mobile PDA/Smartphones.  I wouldn't be 
surprised to see DHCPv6 _Servers_ in a Windows PDA soon.  They're for 
shared links, though.

I would avoid saying that DHCPv6 is not that popular.

But I agree with you SLAAC is the first thing that must work, and parts 
of it must work before any DHCPv6 exchange can take place.

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 20 Sep 2007 08:36:48 -0700

> used for prefix delegation and NOT address assignment to a 

Kuntal,

Not sure, what the confusion is.

3315 is the basic IPv6 DHCP Protocol
3633 is for DHCP IPv6 Prefix Delegation.

So, the host addressing is in the base spec and the PD is
in 3633.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 20 Sep 2007 08:44:22 -0700

Hi Alex,

> Sent: Thursday, September 20, 2007 7:37 AM
> To: Sri Gundavelli
> Cc: 'Chowdhury, Kuntal'; 'Alper Yegin'; 'Julien Laganier'; 
> [email-masked]
> Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was: 

If you see Fig 2, Section 3. the "Address Configuration" is after
the MN receives the RA. This is  specified in other places as well.
The draft did not go into the details of the DHCP signaling. Once,
the PMIP signaling is complete and MAG advertises the prefix on the
MN-AR link, after that point its a normal IPv6 link and the regular
DHCP6 messages can flow through. Its like in fixed infrastructures.
Let me know, if there is any ambiguity in the text.

Thanks
Sri

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 20 Sep 2007 11:59:44 -0400

> Sent: Thursday, September 20, 2007 10:37 AM
[KC>] OK Sri. I get your point and thanks for the clarification. I am
yet to see wide scale use of DHCPv6 for address config in the
wireless/SDO world. That's why; perhaps my opinion is skewed towards
SLAAC :-)

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 20 Sep 2007 09:07:24 -0700

> Sent: Thursday, September 20, 2007 9:00 AM

I agree. SLAAC is the way to go. 

Sri

---

From: Julien Laganier <[email-masked]>
Date: Thu, 20 Sep 2007 18:45:23 +0200

Kuntal,

On Thursday 20 September 2007, Chowdhury, Kuntal wrote:
> [..]
>
> Anyway, the point is that SLAAC is the predominant IPv6 address
> config mechanism. It is widely adopted and implemented. Use of DHCPv6
> for address configuration is not that popular and I am not sure
> whether it is even used anywhere or not.

I do not think this mailing list and working group are the right places 
to debate about merits and popularity of DHCP and SLAAC.

Both are standard track IETF specification for address allocation, hence 
we should not prevent use of either.

--julien

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 20 Sep 2007 09:49:14 -0700

> Sent: Thursday, September 20, 2007 9:45 AM
> To: Chowdhury, Kuntal
> Cc: Sri Gundavelli; Alper Yegin; [email-masked]

I agree with this. The point is that the PMIP6 spec will
interoperate with other standard specs. If a given deployment
chooses SLAAC or DHCPv6 is not our business.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Sep 2007 18:51:04 +0200

Hi Sri,

Sri Gundavelli wrote:
>> Sri Gundavelli wrote:
>>>> -----Original Message----- From: Chowdhury, Kuntal 
>>>> [mailto:[email-masked]] Sent: Thursday, 
>>>> September 20, 2007 7:14 AM To: Alper Yegin; Julien Laganier Cc:
>>>>  [email-masked] Subject: RE: DHCPv6 deployment in PMIPv6
>>>> domain (Was: [netlmm]Commentsondraft-05)
>>>> 
>>>> Is DHCPv6 used for IPv6 address config for a host? If yes, 
>>>> could you please point out which DHCPv6 option is used for 
>>>> that?
>>>> 
>>> RFC-3315.
>> 
>> Like at least for example how is the DHCP CONFIRM message used? How
>> or is REBIND used or not?
>> 
> If you see Fig 2, Section 3. the "Address Configuration" is after the
>  MN receives the RA. This is  specified in other places as well. The 
> draft did not go into the details of the DHCP signaling. Once, the 
> PMIP signaling is complete and MAG advertises the prefix on the MN-AR
>  link, after that point its a normal IPv6 link and the regular DHCP6 
> messages can flow through. Its like in fixed infrastructures. Let me 
> know, if there is any ambiguity in the text.

Right... regular.  But still.

For example, draft v5:
>   When stateful address autoconfiguration is supported on the link, the
>    mobile node can obtain the address configuration from the DHCPv6
>    server using DHCPv6 client protocol, as specified in DHCPv6
>    specification [RFC-3315].

When DHCPv6 is used and the mobile does a handover by disconnecting from
the old link and connecting to the new link then the mobile doesn't
auto-configure a new address, or going from standby to live mode - it
reuses the old one.  So it does not 'obtain' a new address instead it
tells the Server to use the old one, with the CONFIRM message.  It can
be rejected by the Server, but our intent here is of course to use same
address on every MAG.

This is what happens on shared links now.

In a PMIP6 system one wouldn't like mobile to  use RENEW, also because
mobile would keep same address.

Then for all DHCPv6 message we can make thoughts about which are more
appropriated to a PMIP6 domain where the mobile doesn't change its address.

All this for PMIPv6 on systems with wireless access as shared links, not
point-to-point.

Alex

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Thu, 20 Sep 2007 19:18:49 +0200

Hi,

the conclusion in this thread is a bit surprising to me.
There is nothing wrong with SLAAC AFAIK, but whether addresses are managed or not, I guess it's the decision of the network administrator

After all, the hiopt draft is defined to provide the HoA via DHCPv6, isn't it?
 
Anyway, I presume that this discussion is out of scope

Regards

federico

-----Message d'origine-----
De : Sri Gundavelli [mailto:[email-masked]] 
Envoyé : jeudi 20 septembre 2007 18:07
À : 'Chowdhury, Kuntal'; 'Alper Yegin'; 'Julien Laganier'
Cc : [email-masked]
Objet : RE: DHCPv6 deployment in PMIPv6 domain (Was:[netlmm]Commentsondraft-05)

> > > [KC>] I also thought so, until someone told me that DHCPv6 is 
> > > primarily used for prefix delegation and NOT address assignment to 
> > > a host. If you
> > 
> > Kuntal,
> > 
> > So, the host addressing is in the base spec and the PD is in 3633.
> > 

Sri

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 20 Sep 2007 13:20:33 -0400

> From: julien laganier [mailto:[email-masked]] On Behalf Of
> Julien Laganier
> Sent: Thursday, September 20, 2007 11:45 AM
> To: Chowdhury, Kuntal
[KC>] I totally disagree. Continuing to debate over things that are
unlikely to be used is not a meaningful way to use this list either.

> we should not prevent use of either.
[KC>] I don't think the debate is about preventing the use of DHCPv6
with PMIP6. The debate is more on practicality and the use case. So, far
the use cases are heavily skewed towards SLAAC.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 20 Sep 2007 10:24:49 -0700

Hi  Federico,

> From: DE JUAN HUARTE FEDERICO 
> [mailto:[email-masked]] 
> Sent: Thursday, September 20, 2007 10:19 AM
> To: Sri Gundavelli
> Cc: [email-masked]; Chowdhury, Kuntal; Alper Yegin; Julien Laganier
> Subject: RE: DHCPv6 deployment in PMIPv6 domain 
> (Was:[netlmm]Commentsondraft-05)
> 
> Hi,
> 
> There is nothing wrong with SLAAC AFAIK, but whether 
> addresses are managed or not, I guess it's the decision of 
> the network administrator
> 

:)
More confusion. There is no conclusion here. I only expressed
my preference for address configuration based on SLAAC. No way,
that implies, we are not supporting DHCP based addressing. Both,
are equally supported with out any preference. Sorry for the
confusion. Lets close this thread.

Just to conclude, Julien's point was that we may have to add
one or two points on the use of DHCPv6 in PMIP6. We will do
that. We should close this thread now.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Sep 2007 19:37:15 +0200

> that. We should close this thread now.

Please don't close threads so quickly.  Please let it develop and clarify.

I agree on the intent of Julien's point to add one or two points on the 
use of DHCPv6 in PMIPv6.

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 20 Sep 2007 12:38:40 -0500

Federico,

Just as an FYI:
The Hiopt I-D ( draft-ietf-mip6-hiopt-06.txt) does not provide the HoA.

-Raj

On 9/20/07 12:18 PM, "ext DE JUAN HUARTE FEDERICO"
<[email-masked]> wrote:

> There is nothing wrong with SLAAC AFAIK, but whether addresses are managed or
> not, I guess it's the decision of the network administrator
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 20 Sep 2007 10:50:03 -0700

Ok.

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 21 Sep 2007 11:22:28 +0200

We should not prevent DHCPv6 to be used with PMIP6, it is up to a network deployment to make this decision. If there are specific deployment concerns, they should be documented in the draft.

domagoj

> Sent: 20. rujan 2007 19:50
> To: 'Alexandru Petrescu'
> Cc: 'DE JUAN HUARTE FEDERICO'; [email-masked]; 'Julien Laganier'
> Subject: RE: DHCPv6 deployment in PMIPv6domain 
> > > Just to conclude, Julien's point was that we may have to 
> add one or 
> > > two points on the use of DHCPv6 in PMIP6. We will do 
> that. We should 
> > > close this thread now.
> > 
> > I agree on the intent of Julien's point to add one or two points on 
> > the use of DHCPv6 in PMIPv6.
> > 
>

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 24 Sep 2007 11:08:48 +0300

Hello everybody,

<Chair hat on>
I think this discussion has gone long enough now. I can see most of the 
support for *allowing* (not mandating, requiring, etc) DHCPv6 on PMIP. 
This question is independent of the link model in use of the access 
network. I can see Kuntal and Alex disagreeing with this, but I cannot 
see anybody else supporting their opinion. Though, Alex has written 
quite big number of mails on the list.

If there is a disagreement on this conclusion, I'm attempted to put this 
under a consensus call. Obviously, I have to discuss it with my co-chair 
first.
<Chair hat off>

For the usage of DHCP, PPP, and so on in different systems, I would hope 
people would do some studying before starting wars about the different 
models. I have put here some references, which I hope would help in this 
work:

1) 3GPP - the main spec for GPRS is 23.060 - you can find the IPv6 
address allocation procedures under

(The version number of the spec tells the release, version 3xx is 
release 99, 4xx is release 4, 5xx release five, etc.)
http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/

2) 3GPP - System Architecture Evolution (SAE) - the future stuff (23.401 
and 23.402):
http://www.3gpp.org/ftp/Specs/html-info/23401.htm
http://www.3gpp.org/ftp/Specs/html-info/23402.htm

2) 3GPP2 - I don't know in which specs everything is in 3GPP2. However, 
at least pre EV-DO the packet core specs are in 
http://www.3gpp2.org/Public_html/specs/tsgp.cfm. Maybe somebody with 
more 3GPP2 knowledge can point to the right ones.

3) WiMax technical documents can be found at 
http://www.wimaxforum.org/technology/documents/

And especially for Alex, the PPP you are seeing in GPRS is most probably 
the PPP between your PC and the phone. The phone has a PPP server for PC 
connectivity. However, it does not run PPP over the radio interface to 
the GGSN (though there is this option in 23.060). I at least don't know 
anybody that would do that, and the only options my phone has are PDP 
Type IPv4 and IPv6.

I hope this helps.

Cheers,

Jonne.

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 24 Sep 2007 11:16:56 +0300

ext Soininen Jonne (NSN - FI/Espoo) wrote:
> Hello everybody,
>
> <Chair hat on>
> I think this discussion has gone long enough now. I can see most of 
> the support for *allowing* (not mandating, requiring, etc) DHCPv6 on 
> PMIP. This question is independent of the link model in use of the 
> access network. I can see Kuntal and Alex disagreeing with this, but I 
> cannot see anybody else supporting their opinion. Though, Alex has 
> written quite big number of mails on the list.
>
> If there is a disagreement on this conclusion, I'm attempted to put 
> this under a consensus call. Obviously, I have to discuss it with my 
> co-chair first.
> <Chair hat off>
>
> For the usage of DHCP, PPP, and so on in different systems, I would 
> hope people would do some studying before starting wars about the 
> different models. I have put here some references, which I hope would 
> help in this work:
>
I forgot to fill this in: "Dynamic IPv6 Address Allocation" is the 
string to search.
> 2) 3GPP - System Architecture Evolution (SAE) - the future stuff 
> (23.401 and 23.402):
> 2) 3GPP2 - I don't know in which specs everything is in 3GPP2. 
> However, at least pre EV-DO the packet core specs are in 
> And especially for Alex, the PPP you are seeing in GPRS is most 
> probably the PPP between your PC and the phone. The phone has a PPP 
> server for PC connectivity. However, it does not run PPP over the 
> radio interface to the GGSN (though there is this option in 23.060). I 
> at least don't know anybody that would do that, and the only options 
> my phone has are PDP Type IPv4 and IPv6.
>
> I hope this helps.
>
> Cheers,
>
> Jonne.
>