Subject: Re: [netlmm] IPv4 Support

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Apr 2007 11:58:04 -0700

Hi Alex, I realized I never got back to you on this. Here is a
call flow for this. I haven't show the DHCP server in the call
flow.

Lets check if we are all on the same page on this topic.

Vijay

Vijay Devarapalli wrote:
> Hi Alex,
> 
> Instead of trying to answer your email point-by-point we 
> will try to put out a call flow for this.
> 
> Vijay
> 
>> -----Original Message-----
>> From: Alexandru Petrescu [mailto:[email-masked]] 
>> Sent: Tuesday, March 13, 2007 12:28 PM
>> To: Vijay Devarapalli
>> Cc: Alexandru Petrescu; Behcet Sarikaya; Jari Arkko; [email-masked]
>> Subject: Re: [netlmm] IPv4 Support
>>
>> Vijay Devarapalli wrote:
>>> Alexandru Petrescu wrote:
>>>> Vijay Devarapalli wrote:
>>>>> Hello Alex and Behcet,
>>>>>
>>>>> draft-sgundave-mip6-proxymip6-02 also provides support for an
>>>>> IPv4-only mobile node. The mobile node need not have a dual
>>>>> stack. See section 5.6.
>>>>>
>>>>> The IPv4 home address given to the mobile node is from a shared
>>>>> prefix from the LMA. There is no per-MN IPv4 prefix.
>>>>  >
>>>>> Shared prefix is out of scope currently only for IPv6 addresses
>>>>> for the mobile node.
>>>> So can one say PMIPv6 does shared-prefix for IPv4 but 
>> prefix-per-MN 
>>>> for IPv6?
>>> Yes. That is what is assumed in 
>> draft-sgundave-mip6-proxymip6-02 currently.
>>>>> The MAG gets the IPv4 address for the mobile node from the LMA
>>>>> using Proxy BU/Proxy BAck messages. After that the address is
>>>>> assigned to the mobile node using DHCP.
>>>> How does  DHCP implementation on MAG know to _not_ do DHCP?
>>> I don't understand this question.
>> Well who does DHCP DISCOVER?  MN.  Who does DHCP ACK?  MAG.
>>
>> How does MAG know to _not_ relay the DISCOVER to DHCP Server and do 
>> P-BU/BAck instead?  Is that a DHCP modification?  Shouldn't 
>> that be made 
>> clear that PMIPv6 requires DHCP modifications?
>>
>>>> This is what you imply: LMA gets DHCP request and then obtains the 
>>>> IPv4 address with PBU/PBAck.
>>> The DHCP request does not go to the LMA. Only upto the MAG. Proxy 
>>> BU/Proxy BAck is used between the MAG and the LMA.
>> How does MAG _know_ to _not_ send the DHCP Request received 
>> from MN?  A 
>> DHCP implementation _does_ forward the DHCP Request.  Provided it's a 
>> DHCP Relay, of course.  I hope both you and me assume the MAG 
>> is a DHCP 
>> Relay.
>>
>> Besides, it's not the DHCP Request that MAG receives first, it's the 
>> DHCP DISCOVER.  It's upon DHCP DISCOVER that MAG should act, not upon 
>> DHCP Request.
>>
>> Alex
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email 
>> ______________________________________________________________________
>>
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Apr 2007 21:39:07 +0200

Vijay Devarapalli wrote:
> Hi Alex, I realized I never got back to you on this. Here is a call
> flow for this. I haven't show the DHCP server in the call flow.

:-) good I remember too now.  It's a long discussion :-)

> Lets check if we are all on the same page on this topic.

One would make sure the 'Access Auth' phase doesn't deliver an IPv4
address to the mobile node.  On a IPv4 point to point link with PPP and
Radius one does both auth and address allocation.

The DHCPv4 exchange seems to approach it right.   The DHCP Offer and
Request you picture between MN and MAG could extend to the DHCP Server,
which I assume to be different than the MAG (a DHCP Relay), by a certain
SDO.

You seem to have already made a decision that PBack brings the IPv4
address to MN, whereas it could have been done with a real DHCP Offer
and Ack, not simulated.

I think we could ponder what is easier to implement: build a new DHCP
Proxy entity plus ProxyMIPv6/IPv4, or maybe reuse a complete DHCPv4
implementation, no modification on it, and use its messages to trigger
the ProxyBU.

Then there's this question of differentiating the handover from initial
attachment.  The DISCOVER is sent only at initial attachment (usually).
  Upon handover, usually, only the REQUEST is sent, no DISCOVER.  Remark,
as you, I'm trying to have a complete reuse of the DHCP implementation
on MN, no modification of DHCP.

But yes, the picture makes sense to me.  Let's see other oppinions.
We'll surely need to talk this to the DHC WG as well.

Alex

> 
> Vijay
> 
> Vijay Devarapalli wrote:
>> Hi Alex,
>> 
>> Instead of trying to answer your email point-by-point we will try
>> to put out a call flow for this.
>> 
>> Vijay
>> 
>>> -----Original Message----- From: Alexandru Petrescu
>>> [mailto:[email-masked]] Sent: Tuesday, March 13,
>>> 2007 12:28 PM To: Vijay Devarapalli Cc: Alexandru Petrescu;
>>> Behcet Sarikaya; Jari Arkko; [email-masked] Subject: Re:
>>> [netlmm] IPv4 Support
>>> 
>>> Vijay Devarapalli wrote:
>>>>>> draft-sgundave-mip6-proxymip6-02 also provides support for
>>>>>> an IPv4-only mobile node. The mobile node need not have a
>>>>>> dual stack. See section 5.6.
>>>>>> 
>>>>>> The IPv4 home address given to the mobile node is from a
>>>>>> shared prefix from the LMA. There is no per-MN IPv4 prefix.
>>>>>> 
>>>>>> 
>>>>>> Shared prefix is out of scope currently only for IPv6
>>>>>> addresses for the mobile node.
>>>>>> The MAG gets the IPv4 address for the mobile node from the
>>>>>> LMA using Proxy BU/Proxy BAck messages. After that the
>>>>>> address is assigned to the mobile node using DHCP.
>>> How does MAG know to _not_ relay the DISCOVER to DHCP Server and
>>> do P-BU/BAck instead?  Is that a DHCP modification?  Shouldn't
>>> that be made clear that PMIPv6 requires DHCP modifications?
>>> 
>>>>> This is what you imply: LMA gets DHCP request and then
>>>>> obtains the IPv4 address with PBU/PBAck.
>>>> The DHCP request does not go to the LMA. Only upto the MAG.
>>>> Proxy BU/Proxy BAck is used between the MAG and the LMA.
>>> How does MAG _know_ to _not_ send the DHCP Request received from
>>> MN? A DHCP implementation _does_ forward the DHCP Request.
>>> Provided it's a DHCP Relay, of course.  I hope both you and me
>>> assume the MAG is a DHCP Relay.
>>> 
>>> Besides, it's not the DHCP Request that MAG receives first, it's
>>> the DHCP DISCOVER.  It's upon DHCP DISCOVER that MAG should act,
>>> not upon DHCP Request.
>>> 
>>> Alex
>>> 
>>> 
>>>  This email has been scanned by the MessageLabs Email Security
>>> System. For more information please visit
>>> http://www.messagelabs.com/email 
>> _______________________________________________ netlmm mailing list
>>  [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Apr 2007 11:01:44 +0300

Vijay,

> call flow for this. I haven't show the DHCP server in the call

This looks pretty clear to me, thanks.

Like Alex, I would be interested in seeing the movement version
of this diagram. Also, do you plan to support non-DHCP cases,
such as when the link layer supports IP address assignment
(e.g., PPP, GPRS)?

Jari

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 20 Apr 2007 13:34:16 -0400

Alex,

Please see inline...

> Sent: Monday, April 16, 2007 2:39 PM
> To: Vijay Devarapalli
> Cc: [email-masked]
[KC>] You are correct. In the PPP (LCP/IPCP) based MN-AR link, the IPv4
address assignment may happen at this step. Here is a call flow that
shows the PPP scenario in more details:

     +----+                  +-------+              +-------+   +-----+
     | MN/|                  |MAG/NAS|              | LMA   |   |AAA  |
     |User|                  |       |              |       |   |     |
     +----+                  +-------+              +-------+   +-----+
       |                         |                      |          |
       |    LCP (CHAP/PAP)       |                      |          |
    1) |<----------------------->|<---------AAA(Auth/CHAP/PAP)---->|
       |                         |                      |          |
       | IPCP Cfg-Req [v4add]    |                      |          |
    2) +------------------------>|                      |          |
       |                         | PBU [v4HoAExt]       |          |
    3) |                         +--------------------->|          |
       | IPv6CP Cfg-Req[nasv4addd]                      |          |
    4) |<------------------------+                      |          |
       |                         | PBA [v4HoAExt(HoA)]  |          |
    5) |                         |<---------------------+          |
       | IPv6CP Cfg-NAK[v4add(HoA)]                     |          |
    6) |<------------------------+                      |          |
       |                         |                      |          |
       | IPv6CP Cfg-ACK          |                      |          |
    7) +------------------------>|                      |          |
       |                         |                      |          |
       | IPv6CP Cfg-Req[v4add(HoA)]                     |          |
    8) +------------------------>|                      |          |
       |                         |                      |          |
       | IPv6CP Cfg-ACK          |                      |          |
    9) |<------------------------+                      |          |
       |                         |                      |          |

> which I assume to be different than the MAG (a DHCP Relay), by a
certain
[KC>] DHCPDISCOVER may be propagated to an external DHCP server. There
are some issues with that approach, e.g. if the DHCP server assigns the
address but the PBA comes back with an error code, there is no way for
the MN to get IP service and there is no way for the DHCP relay agent
(assumed to be collocated in the NAS/MAG) to inform the DHCP Server of
the PMIP binding failure.

> address to MN, whereas it could have been done with a real DHCP Offer
[KC>] If you are alluding to IPv4 address assignment via a DHCP server,
there are issues (see my previous comment) that are non-trivial to
solve.

> implementation, no modification on it, and use its messages to trigger
[KC>] Please note that DHCP proxy entity is nothing but a DHCP server.
We submitted an I-D in DHC WG and presented it during San Diego IETF. It
was made clear to us that DHCP server won't have to a physical node with
IP address repository. It can be part of the NAS and it can fetch IP
address from external sources via any mechanism such as PMIP. The I-D is
available here:
http://tools.ietf.org/wg/dhc/draft-sarikaya-dhc-proxyagent-00.txt

> on MN, no modification of DHCP.
[KC>] I am not sure why the MN has to send a DHCP message upon handover?
As long as the T1, T2 timers (renew and rebind) are valid, there is no
need to send DHCP messages for IP address management. If the MN
disconnects before the T1, T2 timers are expired, the MN's DHCP stack
should detect that and transition to proper state in DHCP state machine.
For inter MAG HO, there are various ways to deal with the situation:
context transfer, AAA interaction etc. are some possible ways.