Subject: [netlmm] FW: New Version Notification for draft-ietf-netlmm-proxymip6-01

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 18 Jun 2007 18:13:13 -0700

We have posted the -01 version of the PMIP6 draft.
We have fixed some issues and we need to work on
few more. Good amount of changes went into to the
MAG section. We will try to do the updates more
frequently. This is not perfect yet, but on track.

Sri

> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]] 
> Sent: Monday, June 18, 2007 6:00 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: New Version Notification for draft-ietf-netlmm-proxymip6-01 
> 
> 
> A new version of I-D, draft-ietf-netlmm-proxymip6-01.txt has 
> been successfuly submitted by Sri Gundavelli and posted to 
> the IETF repository.
> 
> Filename:	 draft-ietf-netlmm-proxymip6
> Revision:	 01
> Title:		 Proxy Mobile IPv6
> Creation_date:	 2007-06-18
> WG ID:		 netlmm
> Number_of_pages: 49
> 
> Abstract:
> Host based IPv6 mobility is specified in Mobile IPv6 base
> specification [RFC3775].  In that model, the mobile node is
> responsible for doing the signaling to its home agent to enable
> session continuity as it moves between subnets.  The design principle
> in the case of host-based mobility relies on the mobile node being in
> control of the mobility management.  Network based mobility allows IP
> session continuity for a mobile node without its involvement in
> mobility management.  This specification describes a protocol
> solution for network based mobility management that relies on Mobile
> IPv6 signaling and reuse of home agent functionality.  A proxy
> mobility agent in the network which manages the mobility for a mobile
> node is the reason for referring to this protocol as Proxy Mobile
> IPv6.
>                                                               
>                     
> 
> 
> The IETF Secretariat.

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

---

From: "Kalin Getov" <[email-masked]>
Date: Wed, 20 Jun 2007 12:36:17 +0200

Hello Sri, all...

some minor comments on the new version...

Section 4 says, that an LMA could use AAA to verify if MAG is authorized to send PBUs on behalf of MNs.
Section 5 says, LMA has typically a list of authorized MAGs.
Do you mean that AAA (or whatever) is used once to put one MAG into this list or each time a MAG sends a PBU on behalf of MN after handover. Is this list of authorized MAGs a part of the LMA function?. These could be implementation issues also, as the verification method is outside the scope of the base draft...?!

Another thing, section 6.8 says some things about address uniqueness and DAD. The link-local address should be checked for uniqueness (using DAD or ODAD) which is the default IPv6 node behaviour (maybe not needed in all cases, but anyway), but the last part of section 6.8 says:
    "This issue is not relevant to the mobile node's global address.
   Since, there is a unique home network prefix for each mobile node,
   the uniqueness for the mobile node's global address is ensured on the
   access link."

Me and my colleagues are still a little bit confused. Should the MN wait for the DAD of the link-local adress before it accepts the global address for valid, or the global address could be used directly after the reception of the RA from the MAG, emulating the home link?

Maybe a little bit clearer statement should be made in the draft, IMHO.

Regards,
Kalin

-- 
******************************************
Best Regards
Kalin Getov

[email-masked]
******************************************

Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 22 Jun 2007 00:16:33 -0700

Hi Kalin,

> From: Kalin Getov [mailto:[email-masked]] 
> Sent: Wednesday, June 20, 2007 3:36 AM
> To: Sri Gundavelli
> Cc: [email-masked]
> Subject: Re: [netlmm] FW: New Version Notification 
> fordraft-ietf-netlmm-proxymip6-01
> 
>   Hello Sri, all...
> 

Sure. Thanks for the comments.

> Section 4 says, that an LMA could use AAA to verify if MAG is 
> authorized to send PBUs on behalf of MNs.
> Do you mean that AAA (or whatever) is used once to put one 
> MAG into this list or each time a MAG sends a PBU on behalf 
> of MN after handover. Is this list of authorized MAGs a part 
> of the LMA function?. These could be implementation issues 
> also, as the verification method is outside the scope of the 
> base draft...?!
> 

The specifics on how the LMA checks if a MAG is allowed to
send PBU's is upto the implementation and that probably we
should not specify in this document. Its typically a configuration
on the LMA. If I were to implement this, I'd provide a config
knob on the LMA for controlling this aspect. Your implementation
may choose to go to AAA or even skip, in a trusted network.

> Another thing, section 6.8 says some things about address 
> uniqueness and DAD. The link-local address should be checked 
> for uniqueness (using DAD or ODAD) which is the default IPv6 
> node behaviour (maybe not needed in all cases, but anyway), 
> but the last part of section 6.8 says:
> Me and my colleagues are still a little bit confused. Should 
> the MN wait for the DAD of the link-local adress before it 
> accepts the global address for valid, or the global address 
> could be used directly after the reception of the RA from the 
> MAG, emulating the home link?
> 

Sure. The text is stating that the global address uniqueness
exists on that link. When a DNAv6-enabled MN moves to a new
MAG, there is a possibility it will trigger the DAD operation.
We are discussing the issues around it.This is assuming the
MN skips the DAD. On your comment on if the MN should wait till
the DAD is complete, sure, its needs to do that. The draft does
not attempt to modify the MN's behaviour and so not sure if we
can recommend any thing what a MN should do or should not do.
We have non normative text for the MN's behaviour. These
optimizations have to be addressed at a later stage in a different
doc, such as network forcing a mobile to do/skip DAD ..etc, as
you were talking about.

Sri