Subject: Re: [netlmm] comments on draft-ietf-netlmm-pmip6-ipv4-support-02

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 5 Mar 2008 02:40:58 +0100

Ryuji,

> This issue can be also happened to the original DSMIP.
> If HA provides a private HoA and MN obtains a private CoA at 
> the visiting network, both addresses can be duplicated in 
> some scenarios...

yes... although the issue in DSMIP6 does not affect the AR (i.e. MAG). In DSMIP6 it is the visited domain that allocates both the CoA and the AR's address, so there will be no collision. In PMIP case the MN's IP address comes from a different domain (LMA) and thus it may collide with the MAG's address. However, in DSMIP6 case it is possible that there is CoA-HoA collision as they may be allocated by different administrative domains. Such collision is not visible to the foreign network, it only affects the MN.

> One solution for this is to prohibit using a private home 
> address in DSMIP.
> I'm not sure whether this modification is acceptable or not..

This seems a bit drastic. In PMIP case we could mandate that MAGs must be configured with public IP address on the interface facing the MN. 

> MAG can learn the MS type (v4 or v6) by receiving the IPv4 
> address ack  
> option.
> However, if DHCP is used, MAG need to be either DHCP server or DHCP  
> relay.
> After receiving the PBA, It might be too late to interact with DHCP  
> sequence.

hm... not if the PBU is triggered by the link attachment.

> I think MAG should know the client type before sending PBU.

Ideally a MAG would establish an IPv6 / IPv4 session only if the MN actually needs it. Knowing a client type or device capabilities (IPv6+IPv4) doesn't necessarily mean that the MN wants to have both IPv6 and IPv4 session. 

regards
domagoj

> -----Original Message-----
> From: RYUJI WAKIKAWA [mailto:[email-masked]] 
> Sent: 29. veljača 2008 17:45
> To: Premec, Domagoj
> Cc: NetLMM List Mailing
> Subject: Re: [netlmm] comments on 
> draft-ietf-netlmm-pmip6-ipv4-support-02
> 
> Dear Premec,
> 
> Thanks for comments. I apologize my late reply.
> 
> We didn't submit the new version at the deadline of this IETF.
> Sri and I are working on the document right now and will 
> upload the new document to webserver soon.
> We'll send the URL whenever it's ready.
> 
> On 2008/02/20, at 0:24, Premec, Domagoj wrote:
> 
> > Hi Ryuji,
> >
> > I reviewed the IPv4-over-PMIP6 draft and I have some questions to 
> > which I couldn't find answers in the draft, please see my detailed 
> > comments below.
> > Private addresses:
> > The document doesn't handle private IP addresses 
> explicitely. I think 
> > there are some issues resulting from the use of private IP 
> addresses 
> > and it would be good if the document would describe them.
> > Where appropriate, a hint at the solution could also be provided.
> 
> We basically follow the DSMIPv6 spec..
> DSMIPv6 supports private address for both CoA and HoA. 
> Therefore, PMIP also supports private address :-)
> 
> We don't see any issues to support private address so far.
> If you see any PMIP specific issues of the private address 
> use, we'll clearly address the issues.
> 
> > MAGs (access network) and LMA (core network) could be in different 
> > administrative domains. MAGs in the access network are 
> using private 
> > addresses for their own addresses and LMA assigns private 
> addresses to 
> > the MNs. It may happen that the LMA assigns the address x to the MN 
> > and that this same address is used by the MAG as its own 
> address (on 
> > the interface facing the MN). This type of collision is somewhat 
> > similar to the LLA collision in the baseline document. The solution 
> > could be similar to the solution for LLA in the baseline spec.
> 
> interesting issue:-)
> Yes, this is problem. But it looks like this is not specific to PMIPv6
> v4 support work.
> This issue can be also happened to the original DSMIP.
> If HA provides a private HoA and MN obtains a private CoA at 
> the visiting network, both addresses can be duplicated in 
> some scenarios...
> 
> One solution for this is to prohibit using a private home 
> address in DSMIP.
> I'm not sure whether this modification is acceptable or not..
> 
> > If the MAG is part of multiple netlmm domains it may happen 
> that LMAs 
> > from different domains assign the same address to the MNs 
> attached to 
> > the same MAG. The MAG can handle such a situation and keep the MNs 
> > with the same addresses apart (as far as those addresses come from 
> > different LMAs). Although the solution is implementation 
> specific and 
> > requires no protocol changes it may be worthwhile to make the 
> > implementors aware of this situation.
> 
> OK, i agree that there are some tricky scenarios when private 
> addresses are used in PMIP.
> This should be also described in the DSMIPv6 base document, too.
> We'll prepare for texts about the private address usage.
> 
> >
> > The baseline spec allows for local routing at the MAG. Usage of  
> > private addresses makes this more complicate. If the MNs are from  
> > different netlmm domains then local routing for such MNs should be  
> > disabled, otherwise MN might end up talking to a wrong CN.
> 
> Right. MAG SHOULD NOT operate local routing if the source and  
> destination addresses are private.
> We'll fix this.
> 
> > Default router:
> > The baseline spec describes the issues related to the 
> default router  
> > and the MN movement / link change (section 6.9.3). IPv4 host may  
> > learn the default router address via DHCPv4 and RS/RA. I 
> would like  
> > to see a similar paragraph for v4, discussing how the host 
> maintains  
> > its default router list accross movements and any related issues.
> 
> Right.
> Sri actually have prepared some texts for default router handling.
> 
> 
> > Dual stack MS
> > section 3.1 IPv4 Home Address Assignment
> > Besides the two message flows for v4 address assignment, I would  
> > like to a see an additional message flow for a dual stack MS which  
> > is assigned both IPv6 and IPv4 address. Both figure 2 and figure 3  
> > leave the impression that DHCPv4 messages are used as a 
> trigger for  
> > PBU. This is in contrast to v6 case where the link 
> attachment event  
> > is used to trigger PBU. If the MS is dual stacked, will 
> there be two  
> > PBUs, one for v6 upon the attachment to the link, and a second one  
> > for v4 address when the DHCPv4 message is detected?
> 
> RIght, PBU is triggered by the link attachment, and not by the DHCP  
> message.
> The figure can be misread somehow..
> We'll fix the figures.
> 
> Only one PBU is sufficient for boht IPv4 and IPv6 HoA as DSMIPv6 does.
> 
> > Is the MAG able to remove only v4 HoA from the LMA? For 
> example, if  
> > the MS is dual stacked and it sends DHCPRELEASE, the MAG should be  
> > able to remove the v4 HoA but leave the v6 part in the BCE intact.  
> > I'm not sure if the protocol allows for it.
> 
> Good point.
> 
> DSMIP actually cannot operate this.
> There is no way to register a binding only for IPv4 HoA, because
> the source address of the inner IPv6 header MUST be set to IPv6 home  
> address.
> DSMIPv6 always assumes IPv6 home address assignment.
> The HA removes bindings of both IPv4 and IPv6 HoA if the lifetime of  
> BU is set to zero in DSMIP.
> 
> However, in PMIP case, the IPv6 home address is not stored in the  
> source address field.
> The source address is filled with the MAG's address (P-CoA).
> Therefore, the MAG can control which home address will be 
> registered to
> LMA with a single BU by changing the carried mobility options.
> 
> For example,
> - If MAG registers only IPv4 home address, it can include IPv4 home  
> address option only.
> - If it registers only IPv6 home address, it can include Home 
> Network  
> Prefix option only.
> 
> > What if the lease time for v4 HoA expires? Is MAG always able to  
> > detect this and does it need to react? If LMA detects lease time  
> > expiry, is it able to tell the MAG to revoke only v4 
> session? (maybe  
> > lease time and binding lifetime could be kept synchronized to  
> > minimize the issues?)
> 
> If DHCP is used, MAG (DHCP-S or DHCP-R) can generate/intercept the  
> DHCP message for the lease expiration.
> MAG can send a de-registration proxy binding update to LMA.
> I am not sure whether IKE assigns the lease time to IPv4 home 
> addresses.
> 
> Anyway, if LMA controls the lease time, LMA must revoke the 
> v4 session.
> We need some revocation mechanism here...Ahmad!
> 
> In DSMIP, when MN acquires an IPv4 HoA through the binding 
> registration
> (set 0.0.0.0 in the IPv4 home address option),  there is no 
> lease time  
> for IPv4 home address.
> 
> > How about requireing that v4-capable MAG must accept the IPv4  
> > Address Acknowledgment option in the BAck even if it did 
> not put the  
> > IPv4 Home Address option in the BU? This would address the case  
> > where the new MAG is not aware of IP session types (v6/v4) at the  
> > previous MAG. If a new MAG would send a PBU with only the 
> NHP option  
> > (default behaviour) the LMA would still be able to tell it 
> that the  
> > MS has a v4 session and the HoA for that v4 session.
> 
> yes and no.
> MAG can learn the MS type (v4 or v6) by receiving the IPv4 
> address ack  
> option.
> However, if DHCP is used, MAG need to be either DHCP server or DHCP  
> relay.
> After receiving the PBA, It might be too late to interact with DHCP  
> sequence.
> 
> I think MAG should know the client type before sending PBU.
> 
> > DHCP server:
> > section 3.1
> > Would it make sense to require the DHCP server to set the subnet  
> > mask for v4 HoA to 255.255.255.255? This would be in 
> accordance with  
> > a point-to-point link model.
> 
> Correct.
> Otherwise ARP is run for destination addresses of the same subnet.
> We'll fix this.
> 
> > Letting the MN go into the REBIND state negatively affects the MN  
> > idle mode operation, there will be many retransmissions waking up  
> > the MN. It would be helpful to mention this interaction in 
> the spec  
> > so that deployments are aware of the trade-offs before they decide  
> > which option to use.
> 
> OK
> 
> >
> >
> > editorial:
> >
> > section 1
> >> This specification requires that the local mobility anchor and the
> >>  mobile access gateway are both IPv6 capable and IPv6 enabled,
> >>  irrespective of the type of transport network (IPv4 or IPv6),
> >>  connecting these two entities.
> > At the MAG, we can differentiate between the IPv6 support towards  
> > the LMA and the IPv6 support for the hosts. I agree that former is  
> > mandatory. I think it makes sense to allow MAGs to support only v4  
> > on interfaces facing the MN. Maybe this could be clarified in the  
> > paragraph above?
> 
> Sure. The point is that both LMA and MAG MUST have IPv6 address to  
> exchange binding signals.
> We didn't clearly mention that IPv6 is supported which 
> interface, here.
> 
> > section 3:
> >> Further, when the mobile node after
> >>  obtaining the IPv4 or IPv4/IPv6 address configuration on 
> the access
> >>  link, performs an inter-technology handoff, the network 
> will ensure
> >>  the mobile node will be able to use the same IPv4/IPv6 address
> >>  configuration on the new interface.
> > Not every inter-tech handover preserves the IP session, the 
> baseline  
> > spec provides a set of rules to determine if this is a 
> handover or a  
> > simultaneous access. Please add a pointer to section 5.4 of the  
> > baseline spec.
> 
> OK.
> 
> > section 3.1
> >> The mobile access gateway MUST set the known IPv4 home
> >>  prefix to the IPv4 Home Address field and the Pref field 
> of the IPv4
> >>  home address option [ID-DSMIP6].
> > It doesn't read well, maybe it could be re-worded:
> > "The mobile access gateway MUST use the obtained IPv4 home address  
> > to initialize the IPv4 Home Address and Pref fields in the 
> IPv4 Home  
> > Address option."
> > section 3.2.2
> >> However, since Proxy
> >>     Mobile IPv6 supports only IPv4 capable node, IPv6 home 
> address is
> >>     not always available on the terminal.
> > Suggests re-wording:
> > "However, since Proxy Mobile IPv6 supports also IPv4-only nodes,  
> > IPv6 home address is not always available on the terminal."
> >
> >> Receiving Binding Registration Reply:
> > s/Binding Registration Reply/Binding Acknowledgment message/
> >
> >>  o  The IPv4 Home Address option [ID-DSMIP6] MUST be present.  The
> >>     address value MAY be set 0.0.0.0 or to a specific value.
> > Add following sentence: "If IPv4 Home Address Option is included  
> > then the Home Network Prefix option [ID-PMIP6] MAY be omitted."
> 
> agree, we'll fix all the above correction.
> 
> >>  o  When a mobile node obtains an IPv4 home address from 
> DHCP server,
> >>     the mobile access gateway SHOULD record the assigned IPv4 home
> >>     address in the policy profile.  A new mobile access gateway can
> >>     send a proxy binding update when a mobile node roams to the new
> >>     mobile access gateway.
> > I'm confused by the last sentence. Do you mean that the old 
> MAG can  
> > send a de-registration PBU when the MN goes away? If yes, please  
> > reword to make it more clear.
> 
> This text has been removed.
> 
> > Figures 4, 5, 8 and 11 show the structure of PBU and PBAck 
> messages.  
> > Some options are marked as optional, some as mandatory and 
> some are  
> > not marked at all. I would suggest to flag all options as either  
> > mandatory or optional.
> 
> ok, we will fix these.
> 
> Thanks again for detailed comments.
> I apologize our delay to submit the new version.
> 
> I'll send another mail to MEXT to point out some fundamental 
> issues of  
> DSMIP.
> 
> regards,
> ryuji
> 
> ps. Mobicom08 and Mobiarch08 CFP are attached below!!!!
> 
> --------------------------------------------------------------
> -----------
>                         CALL FOR PAPERS
> 
>                            MobiCom 2008
>             The Fourteenth Annual International Conference
>                 on Mobile Computing and Networking
> 
>                         September 14-19, 2007
>              	   San Francisco Bay Area, CA, USA
>               http://www.sigmobile.org/mobicom/2008/
>                     Sponsored by ACM SIGMOBILE
> --------------------------------------------------------------
> -----------
> ACM MobiCom is the premier international conference dedicated to
> addressing the challenges in the areas of mobile computing and
> wireless and mobile networking.  It has served as an exciting
> international forum since 1995, addressing networks, systems,
> algorithms, and applications that support the symbiosis of mobile
> computers and wireless networks. This year, we will continue
> this tradition, but we especially encourage the submission of papers
> in the experimental systems area.  This area has seen exciting
> developments in recent years and explicit efforts will be taken to
> represent it strongly at MobiCom this year.
> 
> Authors are invited to submit full papers, challenges papers, student
> posters, and research demos and exhibits, presenting new research
> related to the theory or practice of mobile computing and/or wireless
> and mobile networking. All submissions must describe original 
> research,
> not published or currently under review for another conference or
> journal. Areas of interest include, but are not limited to:
> 
>   * Operating system and middleware support for mobile computing and
>     networking
>   * Architectures, protocols, and algorithms to cope with mobility,
>     limited bandwidth, limited power and/or intermittent connectivity
>   * Fundamental understanding of mobile computing and wireless  
> networking
>   * Wireless and mobile techniques for delay tolerant, mobile ad hoc,
>     and wireless sensor networks
>   * Security, privacy, and trustworthiness of mobile and wireless  
> systems
>   * Wireless access technologies (e.g. mesh systems, PANs)
>   * Integration and interworking of wired and wireless networks
>   * Protocols exploiting novel technologies such as UWB, MIMO,
>     directional antennas, and software radios
>   * Techniques for dynamic spectrum use
>   * Architectures, algorithms and protocols for cognitive wireless
>     networks and their integration in the Internet
>   * Modeling, measurement and simulation of mobile networks
>   * Experimental test-beds for mobile/wireless networks
>   * Performance evaluation of mobile and wireless networks, protocols,
>     and systems
>   * Next generation (beyond 802.11) wireless technologies and related
>     systems and protocols
> 
> Submission Instructions
> Detailed instructions on how and where to submit your paper can be
> found at http://www.sigmobile.org/mobicom/2008/cfp.pdf
> 
> IMPORTANT DATES:
> Abstracts submission due: March 7, 2008
> Paper submission due: March 14, 2008
> Notification of acceptance: June 19, 2008
> Camera-ready version due: July 7, 2008
> 
> General Chair - [email-masked]:
> J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC
> 
> Technical Co-Chairs - [email-masked]:
> Raghupathy (Siva) Sivakumar, Georgia Tech
> Peter Steenkiste, Carnegie Mellon University
> 
> FOR MORE INFORMATION: Please contact the General Chair or Program
> Co-Chairs for more information.  For information on ACM 
> SIGMOBILE and  
> the
> MobiCom series of conferences, see http://www.sigmobile.org/ 
> or contact
> [email-masked].
> 
> --------------------------------------------------------------
> -----------
>                           CALL FOR PAPERS
> 
>                          ACM MobiArch 2008
>                    An ACM SIGCOMM 2008 Workshop
>                  Seattle, WA, USA, August 22, 2008
> 
>                The 3rd ACM International Workshop on
>            Mobility in the Evolving Internet Architecture
>               Paper registration deadline: March 17, 2008
> --------------------------------------------------------------
> -----------
> 
>        http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/
> 
> Recent developments in wireless access technologies and mobile devices
> are beginning to make widespread user, terminal and network mobility a
> reality in the commercial Internet. At the same time, the Internet
> architecture struggles to incorporate the functionality that will  
> sustain
> this increasingly more mobile and more dynamic Internet use. Efficient
> mobility management and mobility optimizations, locator-identifier
> splits, multihoming, security and related network operation and
> management functions are still in the early stages of 
> development. It  
> is,
> however, already clear that supporting widespread mobility poses to
> significantly impact the original end-to-end design of the Internet.
> 
> At the same time, critical momentum is building to 
> significantly revise
> or even replace the current Internet architecture. Several substantial
> Future Internet initiatives have started in Europe, the US 
> and Asia, and
> the topic is also actively being discussed in the vendor and network
> operator communities. These Future Internet efforts offer the exciting
> opportunity to design radically different approaches to 
> supporting host
> and network mobility and multihoming, and may eventually lead to an
> internetwork architecture with significantly more advanced mobility
> features than those that the piecemeal extensions of the current  
> Internet
> protocols result in.
> 
> MobiArch'08 welcomes submissions from both researchers and 
> practitioners
> that explore recent advances in architectures, protocols and emerging
> technologies to enable mobility and multihoming in the 
> Internet, as well
> as concepts and designs to support widespread mobility and 
> multihoming  
> in
> future internetworks.  Early results, position papers, systems and
> measurement papers are particularly welcome.
> 
> TOPICS
> MobiArch'08 covers all aspects related to mobility in the current and
> future Internet, including, but not limited to:
> 
>   * Architectures and protocols for mobility support at all layers
>     of the Internet protocol stack, as well as cross-layer approaches
>   * Novel concepts to support widespread mobility and multihoming
>     in a Future Internet
>   * Routing and addressing issues (including locator/identifier
>     splits) and their impact on the Internet architecture
>   * Multihoming, including flow distribution and load-sharing for
>     wireless and mobility
>   * Performance evaluation, experimentation and modeling of
>     Internet mobility
>   * Models for mobility patterns and their experimental validation
>   * New wireless technologies and services and their impact on the
>     Internet architecture
>   * Location management, positioning and data management for
>     wireless and mobility
>   * Accounting, access control, security and privacy issues and
>     their impact on the Internet architecture
>   * Social, economic, scalability and deployment issues
> 
> SUBMISSION GUIDELINES
> Submissions must be no longer than six pages, including all 
> figures and
> references, must be in PDF format, and must follow the ACM formatting
> guidelines 
> (http://www.acm.org/sigs/publications/proceedings-templates).
> Submissions that do not adhere to these requirements will be rejected
> without further review.
> Peer review is single-blind; the authors names and 
> affiliations are to  
> be
> included on the submission. Submissions cannot be previously 
> published  
> or
> be under concurrent review elsewhere. The submission of 
> position papers
> is encouraged; please clearly identify position papers as such when
> submitting.
> Papers may be submitted at http://edas.info/newPaper.php?c=6140
> 
> IMPORTANT DATES
>   March 17, 2008        Registration of paper abstract
>   March 24, 2008        Submissions due
>   May 1, 2008           Notification of acceptance
>   June 9, 2008          Camera ready version due
>   August 22, 2008       Workshop date
> 
> 
> TECHNICAL PROGRAM COMMITTEE
>   Lars Eggert           (co-chair, Nokia Research Center, FI)
>   Linda Doyle           (co-chair, Trinity College, IE)
>   Rui Aguiar            (Universidade de Aveiro, PT)
>   Bengt Ahlgren         (Swedish Institute of Computer Science, SE)
>   Jari Arkko            (Ericsson, FI)
>   Marcelo Bagnulo       (University Carlos III of Madrid, ES)
>   Olivier Bonaventure   (Université Catholique de Louvain, BE)
>   Wesley Eddy           (NASA/Verizon (US)
>   Joseph Evans          (University of Kansas, US)
>   Ted Faber             (USC Information Sciences Institute, US)
>   Stephen Hailes        (University College London, UK)
>   Roger Karrer          (T-Labs, DE)
>   Rajeev Koodli         (Nokia Research Center, US)
>   Donal O'Mahony        (Trinity College, IE)
>   Jörg Ott              (Helsinki University of Technology, FI)
>   Guru Parulkar         (Stanford University, US)
>   Dipankar Raychaudhuri (Rutgers University, US)
>   Dave Thaler           (Microsoft, US)
>   Ryuji Wakikawa        (Keio University, JP)
>   Klaus Wehrle          (RWTH Aachen University, DE)
>   Lixia Zhang           (UCLA, US)
> 
> 
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Mar 2008 10:42:27 +0100

Premec, Ryuji,

On Wednesday 05 March 2008, Premec, Domagoj wrote:
> yes... although the issue in DSMIP6 does not affect the AR (i.e.
> MAG). In DSMIP6 it is the visited domain that allocates both the CoA
> and the AR's address, so there will be no collision. In PMIP case the
> MN's IP address comes from a different domain (LMA) and thus it may
> collide with the MAG's address. However, in DSMIP6 case it is
> possible that there is CoA-HoA collision as they may be allocated by
> different administrative domains. Such collision is not visible to
> the foreign network, it only affects the MN.

The issue of collision of a private IPv4 addresses of MN and MAG looks 
similar to the issue of collision of IPv6 link-local addresses of MN 
and MAGs.

For IPv6 link-local addresses, one of the workaround is for the MAG to 
store the IPv6 link-local addresses of the MN in the binding cache 
entry at the LMA.

The MAG does not send packets to the MN over IPv6 before it retrieves 
the MN's IPv6 HNP. Thus the MAG does not need to have an IPv6 
link-local address on the interface facing the MN prior to receiving 
the IPv6 HNP that comes together with the IPv6 link-local of the MN. 
Then the MAG can pick up for itself an IPv6 link-local that does not 
collide with that of the MN, and send the RA.

> This seems a bit drastic. In PMIP case we could mandate that MAGs
> must be configured with public IP address on the interface facing the
> MN.

I don't think this is necessary. 

If it is desired that the MAG use private IPv4 addresses, a solution 
similar to the IPv6 link-local workaround can be adopted, it's nearly 
as simple as s/IPv6 link-local/IPv4 private/ :)

The MAG does not send packets to the MN over IPv4 before it retrieves 
the MN's (possibly private) HoA. Thus the MAG does not need to have a 
private IPv4 address on the interface facing the MN prior to receiving 
the IPv4 HoA. Then the MAG can pick up for itself a private IPv4 
address that does not collide with the possibly private IPv4 HoA of the 
MN, and proceed with sending the DHCP offer, etc.

Thoughts?

--julien

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 5 Mar 2008 14:51:51 +0100

Julien,

I agree that the collision of private IPv4 addresses between MN and MAG is similar to the IPv6 link-local address collision described in the baseline spec. I'm fine with eihter solution (v6-like mechanism for collision avoidance or public addresses on MAG).

> The MAG does not send packets to the MN over IPv4 before it 
> retrieves the MN's (possibly private) HoA.

I wonder if this is always the case. v4 Router Advertisment does not carry any MN specific info, could it be sent (possibliy in a response to RS) even before the PBU/PBAck exchange is completed? We should probably explicitely say that MAG is not allowed to send anything to the MS before it gets PBAck.

domagoj

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: 05. ožujak 2008 10:42
> To: [email-masked]
> Cc: Premec, Domagoj; RYUJI WAKIKAWA
> > > If HA provides a private HoA and MN obtains a private CoA at the 
> > > visiting network, both addresses can be duplicated in some 
> > > scenarios...
> >
> > collide with the MAG's address. However, in DSMIP6 case it 
> is possible 
> > that there is CoA-HoA collision as they may be allocated by 
> different 
> > administrative domains. Such collision is not visible to 
> the foreign 
> The issue of collision of a private IPv4 addresses of MN and 
> MAG looks similar to the issue of collision of IPv6 
> link-local addresses of MN and MAGs.
> 
> For IPv6 link-local addresses, one of the workaround is for 
> the MAG to store the IPv6 link-local addresses of the MN in 
> the binding cache entry at the LMA.
> 
> The MAG does not send packets to the MN over IPv6 before it 
> retrieves the MN's IPv6 HNP. Thus the MAG does not need to 
> have an IPv6 link-local address on the interface facing the 
> MN prior to receiving the IPv6 HNP that comes together with 
> the IPv6 link-local of the MN. 
> Then the MAG can pick up for itself an IPv6 link-local that 
> does not collide with that of the MN, and send the RA.
> 
> address in 
> > This seems a bit drastic. In PMIP case we could mandate 
> that MAGs must 
> > be configured with public IP address on the interface facing the MN.
> 
> If it is desired that the MAG use private IPv4 addresses, a 
> solution similar to the IPv6 link-local workaround can be 
> adopted, it's nearly as simple as s/IPv6 link-local/IPv4 private/ :)
>

---

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Mar 2008 15:05:16 +0100

Premec,

On Wednesday 05 March 2008, Premec, Domagoj wrote:
> Julien,
>
> I agree that the collision of private IPv4 addresses between MN and
> MAG is similar to the IPv6 link-local address collision described in
> the baseline spec. I'm fine with eihter solution (v6-like mechanism
> for collision avoidance or public addresses on MAG).

I'd prefer the former since it doesn't unnecessarily restrict 
deployments. Also, given the scarcity of public IPv4 addresses these 
days, and given that the MN-facing MAG IPv4 address is used for nothing 
else than a placeholder in the MN's routing table, I think this is 
definitely a good choice to allow for private IPv4 addresses as 
MN-facing MAG address.

> I wonder if this is always the case. v4 Router Advertisment does not
> carry any MN specific info, could it be sent (possibliy in a response
> to RS) even before the PBU/PBAck exchange is completed? We should
> probably explicitely say that MAG is not allowed to send anything to
> the MS before it gets PBAck.

Since in the v4 case the MN rely on DHCP for address allocation, the 
default router can be configured as part of DHCP as well. Thus I'm not 
sure it makes sense to use v4 router advertisement in NETLMM.

--julien

> > > > the visiting network, both addresses can be duplicated in some
> > > > scenarios...
> > >
> > > MAG). In DSMIP6 it is the visited domain that allocates
> >
> > both the CoA
> >
> > > and the AR's address, so there will be no collision. In
> >
> > PMIP case the
> >
> > > MN's IP address comes from a different domain (LMA) and thus it
> > > may collide with the MAG's address. However, in DSMIP6 case it
> >
> > is possible
> >
> > the foreign
> > > network, it only affects the MN.
> >

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 5 Mar 2008 15:44:09 +0100

Julien,

Yes, it makes sense to allow MAGs to use private IP addresses. IMO it also make sense not to force MAGs to use the collision avoidance mechanism if they are using public IP addresses. We can leave it up to a deployment.

> Since in the v4 case the MN rely on DHCP for address 
> allocation, the default router can be configured as part of 
> DHCP as well. Thus I'm not sure it makes sense to use v4 
> router advertisement in NETLMM. 

The unmodified IP host is free to send the v4 RS anytime it wants, we can't tell the host not to use it. RS/RA exchange is also related to the default router cache at the MN and how it gets updated as the MN moves across MAGs. We don't assume the MN will initiate DHCP when there is a link change.

domagoj

> Sent: 05. ožujak 2008 15:05
> To: [email-masked]
> Cc: Premec, Domagoj
> deployments. Also, given the scarcity of public IPv4 
> addresses these days, and given that the MN-facing MAG IPv4 
> address is used for nothing else than a placeholder in the 
> MN's routing table, I think this is definitely a good choice 
> to allow for private IPv4 addresses as MN-facing MAG address.
> 
> Since in the v4 case the MN rely on DHCP for address 
> allocation, the default router can be configured as part of 
> DHCP as well. Thus I'm not sure it makes sense to use v4 
> router advertisement in NETLMM.
> 
> --julien
> 
> > > From: julien laganier [mailto:[email-masked]] 
> On Behalf 
> > > Of Julien Laganier
> > > The issue of collision of a private IPv4 addresses of MN and MAG 
> > > looks similar to the issue of collision of IPv6 
> link-local addresses 
> > > of MN and MAGs.
> > >
> > > For IPv6 link-local addresses, one of the workaround is 
> for the MAG 
> > > to store the IPv6 link-local addresses of the MN in the binding 
> > > cache entry at the LMA.
> > >
> > > retrieves the MN's IPv6 HNP. Thus the MAG does not need 
> to have an 
> > > IPv6 link-local address on the interface facing the MN prior to 
> > > receiving the IPv6 HNP that comes together with the IPv6 
> link-local 
> > > of the MN.
> > > > be configured with public IP address on the interface 
> facing the 
> > > > MN.
> > >
> > > similar to the IPv6 link-local workaround can be adopted, it's 
> > > nearly as simple as s/IPv6 link-local/IPv4 private/
> > > :)
> > >
> > >
> > >
> > >
> > >
> > > Thoughts?
> > >
> > > --julien
> >

---

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Mar 2008 15:59:29 +0100

Domagoj,

On Wednesday 05 March 2008, Premec, Domagoj wrote:
> Julien,
>
> Yes, it makes sense to allow MAGs to use private IP addresses. IMO it
> also make sense not to force MAGs to use the collision avoidance
> mechanism if they are using public IP addresses. We can leave it up
> to a deployment.

Right, the collision avoidance mechanism can be skipped whenever a MAG 
has a public IPv4 address.

> The unmodified IP host is free to send the v4 RS anytime it wants, we
> can't tell the host not to use it. RS/RA exchange is also related to
> the default router cache at the MN and how it gets updated as the MN
> moves across MAGs. We don't assume the MN will initiate DHCP when
> there is a link change.

The MAG just discard the v4 RS. A host can't assume v4 router discovery 
is deployed everywhere. The default router cache will be updated by 
DHCP. A host should do DHCP when there's a link change, otherwise it 
gets into trouble whenever handover occurs from one link to another. If 
the host doesn't do DHCP then, that's the problem of the host, not of 
DHCP. For a host to work well in a mobile environment, it needs to 
implement DNAv4 (aka RFC4436). If that is the case, the host will 
conclude it changed link since ARP-based reachability tests with the 
previous router will fail, and DHCP will kick in. 

--julien

> > > I agree that the collision of private IPv4 addresses between MN
> > > and MAG is similar to the IPv6 link-local address collision
> >
> > described in
> >
> > > the baseline spec. I'm fine with eihter solution (v6-like
> > > mechanism for collision avoidance or public addresses on MAG).
> >
> > > I wonder if this is always the case. v4 Router Advertisment
> >
> > does not
> >
> > > carry any MN specific info, could it be sent (possibliy in
> >
> > a response
> >
> > > probably explicitely say that MAG is not allowed to send
> >
> > anything to
> >
> > > > > > If HA provides a private HoA and MN obtains a private
> >
> > CoA at the
> >
> > > > > yes... although the issue in DSMIP6 does not affect the AR
> > > > > (i.e. MAG). In DSMIP6 it is the visited domain that allocates
> > > >
> > > > both the CoA
> > > >
> > > > > MN's IP address comes from a different domain (LMA) and thus
> > > > > it may collide with the MAG's address. However, in DSMIP6
> > > > > case it
> > > >
> > > > is possible
> > > >
> > link-local addresses
> > > > of MN and MAGs.
> > > > Then the MAG can pick up for itself an IPv6 link-local
> >
> > that does not
> >
> > > > If it is desired that the MAG use private IPv4 addresses,
> >
> > a solution
> >

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 5 Mar 2008 21:21:52 -0800

Hi Domagoj/Julien,

> > moves across MAGs. We don't assume the MN will initiate DHCP when

Not sure, I follow the thread completly. But, if the concern is
about a potential address collision with the MAG's IPv4 address
on the p2p link, not sure how.

- The MN-AR link is a dynamically created p2p link
- The egress interface of the MAG can certainly have a private IPv4
  address. LMA should not assign a private IPv4 address as IPv4-MN-HoA
  to an MN, matching the IPv4 CoA and when NAT detect is on. Probably
  this check is required in DSMIP6 as well.
- The MAG after completing the signaling with the LMA will obtain
  the IPv4-HoA for the MN and also the default-router address in that
  prefix pool. This will be delivered to the MAG via PMIP signaling.
- The MAG on every access link will function as the DR for the MN
  and will proxy for that DR address, by sending Gratuitous ARP message

So, I dont see any address collision issues. Ignore this, if I did not
follow the thread and I'm on a orthogonal track.

Regards
Sri

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 6 Mar 2008 15:16:47 +0100

Sri,

> - The MN-AR link is a dynamically created p2p link

ok

>   this check is required in DSMIP6 as well.

ok. We were discussing the conflict between the IPv4-MN-HoA and the MAG's address on the interface facing the MN. LMA only knows the v4-CoA which is assigned to the interface facing the LMA.

>   prefix pool. This will be delivered to the MAG via PMIP signaling.

Are you saying that the LMA will allocate a default router address and send it to the MAG in PBAck? We need a new option to carry that additional IPv4 address.

>   and will proxy for that DR address, by sending Gratuitous 

Would LMA need to store the default router address as part of the binding cache and deliver it to the new MAG upon handover?

Your proposal seems in-line with the LLA collision avodiance mechanism in the baseline spec. Julien also suggested such approach. I'm fine with it, too.

thanks
domagoj

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: 06. ožujak 2008 06:22
> To: 'Julien Laganier'; Premec, Domagoj
> Cc: [email-masked]
> Subject: RE: [netlmm] comments on 
> Not sure, I follow the thread completly. But, if the concern 
> is about a potential address collision with the MAG's IPv4 
> address on the p2p link, not sure how.
> 
> So, I dont see any address collision issues. Ignore this, if 
> I did not follow the thread and I'm on a orthogonal track.
> 
> Regards
> Sri
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > The MAG just discard the v4 RS. A host can't assume v4 router 
> > discovery is deployed everywhere. The default router cache will be 
> > updated by DHCP. A host should do DHCP when there's a link change, 
> > otherwise it gets into trouble whenever handover occurs 
> from one link 
> > to another. If the host doesn't do DHCP then, that's the problem of 
> > the host, not of DHCP. For a host to work well in a mobile 
> > environment, it needs to implement DNAv4 (aka RFC4436). If 
> that is the 
> > case, the host will conclude it changed link since ARP-based 
> > reachability tests with the previous router will fail, and 
> DHCP will 
> > kick in.
> > 
> > --julien
> > 
> > > > From: julien laganier 
> [mailto:[email-masked]] On Behalf 
> > > > Of Julien Laganier
> > > > deployments. Also, given the scarcity of public IPv4 addresses 
> > > > these days, and given that the MN-facing MAG IPv4 
> address is used 
> > > > for nothing else than a placeholder in the MN's routing 
> table, I 
> > > > think this is definitely a good choice to allow for 
> private IPv4 
> > > > addresses as MN-facing MAG address.
> > > >
> allocation, 
> > > > the default router can be configured as part of DHCP as 
> well. Thus 
> > > > I'm not sure it makes sense to use v4 router advertisement in 
> > > > NETLMM.
> > > >
> > > > --julien
> > > >

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 6 Mar 2008 07:29:26 -0800 (PST)

Hi Domagoj,

> Are you saying that the LMA will allocate a default router address and send it to the MAG in PBAck? We need a new option to carry that additional IPv4 address.

Yes. Ryuji and me fixed this issue in the latest draft. We had some
discussions on this issue few weeks back and decided to add the DR
option.

> Would LMA need to store the default router address as part of the binding cache and deliver it to the new MAG upon handover?

The DR address in each address pool is managed by the LMA. MAG has no
control on address blocks or the DR's in each block.

> Your proposal seems in-line with the LLA collision avodiance mechanism in the baseline spec. Julien also suggested such approach. I'm fine with it, too.

Cool. You will see this change in the latest version.

Regards
Sri

---

From: Julien Laganier <[email-masked]>
Date: Thu, 6 Mar 2008 16:53:11 +0100

Hi Sri,

the new proposal looks fine with me, I'm looking forward to the updated 
draft.

--julien

On Thursday 06 March 2008, Sri Gundavelli wrote:
> >> - The egress interface of the MAG can certainly have a private
> >> IPv4 address. LMA should not assign a private IPv4 address as
> >> IPv4-MN-HoA to an MN, matching the IPv4 CoA and when NAT detect is
> >> on. Probably this check is required in DSMIP6 as well.
> >
> > ok. We were discussing the conflict between the IPv4-MN-HoA and the
> > MAG's address on the interface facing the MN. LMA only knows the
> > v4-CoA which is assigned to the interface facing the LMA.
> >
> >>   the IPv4-HoA for the MN and also the default-router address in
> >> that prefix pool. This will be delivered to the MAG via PMIP
> >> signaling.
> >
> > Are you saying that the LMA will allocate a default router address
> > and send it to the MAG in PBAck? We need a new option to carry that
> > additional IPv4 address.
>
> > Would LMA need to store the default router address as part of the
> > binding cache and deliver it to the new MAG upon handover?
>
> > Your proposal seems in-line with the LLA collision avodiance
> > mechanism in the baseline spec. Julien also suggested such
> > approach. I'm fine with it, too.
>
> >> Sent: 06. oŸujak 2008 06:22
> >>>> The unmodified IP host is free to send the v4 RS anytime it
> >>>
> >>> wants, we
> >>>
> >>>> can't tell the host not to use it. RS/RA exchange is also
> >>
> >> related to
> >>
> >>>> the default router cache at the MN and how it gets
> >>
> >> updated as the MN
> >>
> >>>> moves across MAGs. We don't assume the MN will initiate DHCP
> >>>> when there is a link change.
> >>
> >> - The egress interface of the MAG can certainly have a private
> >> IPv4 address. LMA should not assign a private IPv4 address as
> >> IPv4-MN-HoA to an MN, matching the IPv4 CoA and when NAT detect is
> >> on. Probably this check is required in DSMIP6 as well.
> >>   the IPv4-HoA for the MN and also the default-router address in
> >> that prefix pool. This will be delivered to the MAG via PMIP
> >> signaling. - The MAG on every access link will function as the DR
> >> for the MN and will proxy for that DR address, by sending
> >> Gratuitous ARP message
> >>
> >>> discovery is deployed everywhere. The default router cache will
> >>> be updated by DHCP. A host should do DHCP when there's a link
> >>> change, otherwise it gets into trouble whenever handover occurs
> >>
> >> from one link
> >>
> >>> to another. If the host doesn't do DHCP then, that's the problem
> >>> of the host, not of DHCP. For a host to work well in a mobile
> >>>>> Sent: 05. oŸujak 2008 15:05
> >>>>> To: [email-masked]
> >>>>> Cc: Premec, Domagoj
> >>>>>> I agree that the collision of private IPv4 addresses
> >>
> >> between MN
> >>
> >>>>>> to RS) even before the PBU/PBAck exchange is completed?
> >>>
> >>> We should
> >>>
> >>>>>>> Sent: 05. oŸujak 2008 10:42
> >>>>>>> To: [email-masked]
> >>>>>>>>> visiting network, both addresses can be
> >>
> >> duplicated in some
> >>
> >>>>>>>>> scenarios...
> >>>>>>>>
> >>>>>>>> yes... although the issue in DSMIP6 does not
> >>
> >> affect the AR
> >>
> >>>>>>>> (i.e. MAG). In DSMIP6 it is the visited domain that
> >>>
> >>> allocates
> >>>
> >>>>>>> both the CoA
> >>>>>>>
> >>>>>>>> MN's IP address comes from a different domain
> >>
> >> (LMA) and thus
> >>
> >>>>>>>> that there is CoA-HoA collision as they may be
> >>
> >> allocated by
> >>
> >>>>>>> different
> >>>>>>>
> >>>>>>> The issue of collision of a private IPv4 addresses
> >>
> >> of MN and
> >>
> >>>>>>> to store the IPv6 link-local addresses of the MN in
> >>>
> >>> the binding
> >>>
> >>>>>>> cache entry at the LMA.
> >>>>>>>
> >>>>>>> IPv6 link-local address on the interface facing the
> >>>
> >>> MN prior to
> >>>
> >>>>>>>>> One solution for this is to prohibit using a
> >>
> >> private home
> >>
> >>>>>>> address in
> >>>>>>>
> >>>>>>>>> DSMIP.
> >>>>>>> similar to the IPv6 link-local workaround can be
> >>
> >> adopted, it's
> >>

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 6 Mar 2008 07:57:17 -0800 (PST)

> the new proposal looks fine with me, I'm looking forward to the updated

Ok !

Thanks
Sri