RE: [netlmm] IPv4 Support

["Chowdhury, Kuntal" <[e-mail]>]

Alex,

Please see inline...

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[e-mail]]
> Sent: Monday, April 16, 2007 2:39 PM
> To: Vijay Devarapalli
> Cc: [e-mail]
> 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) |<------------------------+                      |          |
       |                         |                      |          |


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

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

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



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

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

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