Subject: Re: [netlmm] IPv4 Support

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 22 Apr 2007 23:32:52 +0200

Chowdhury, Kuntal wrote:
> Alex,
> 
> Please see inline...
> 
>> -----Original Message----- From: Alexandru Petrescu 
>> [mailto:[email-masked]] Sent: Monday, April 16, 2007 
>> 2:39 PM To: Vijay Devarapalli Cc: [email-masked] Subject: Re: 
>> [netlmm] IPv4 Support
>> 
>> 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.
>> 
> [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) |<------------------------+                      |          |
>        |                         |                      |          |

Thanks, that looks ok to me, but some arrows seem reverted? (step 4
Cfg-Req is sent by the mobile no?).  Or is this a dump of a message
exchange you've observed with a implementation?

I think a diagram like this should be part of the MN-AR interface draft.

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

Oh, I see.  I think I understand the problem, in that HA and DHCP Server
  don't know about each other's conditions of executing correctly its
function; ie DHCP allocates a home address but HA won't bind that home
address to the MAG's 'care-of' address.  But in that case MN should
still be able to use the home address allocated by DHCP, at least for
some local purposes.

And we can also say that people should configure their networks
correctly, such that situations like this don't occur.

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

Ok.

>> 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.
>> 
> [KC>] Please note that DHCP proxy entity is nothing but a DHCP 
> server.

I've seen this 'DHCP proxy' waived every now and then, but never assumed
it were just a DHCP Server.  If it were only a DHCP Server then it would
allocate addresses automatically.  So, we'd have to specify that a 'DHCP
proxy' doesn't actually allocate addresses.

> 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

So how can this be adopted to be more than a personal proposal?

Is that implemented?

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

Implementations do send Request each time the interface changes status
up/down.

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

Is this something implemented or something you'd like to be implemented?

> For inter MAG HO, there are various ways to deal with the situation:
> context transfer, AAA interaction etc. are some possible ways.

I haven't thought of those.  I think mainly normal behaviour of existing 
DHCP clients upon changing their link layer.  One interface changing to 
a different link does send Request, with some implementations I've tried.

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