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.

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:alexandru.petrescu@gmail.com] Sent: Tuesday, March 13,
>>> 2007 12:28 PM To: Vijay Devarapalli Cc: Alexandru Petrescu;
>>> Behcet Sarikaya; Jari Arkko; netlmm@ietf.org 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
>>  netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm
> 

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

_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm