Subject: Re: [MEXT] Fwd: [netlmm] comments ondraft-ietf-netlmm-pmip6-ipv4-support-02

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

Ryuji, Hesham,
 
> 2. If MN wants to remove a binding only for IPv4 HoA, how can 
> MN de- register the binding?
>    If it sends a deregiatration BU, bindings of both IPv4 and 
> IPv6 HoAs are removed at the HA.

Could the MN send the re-registration BU and leave out the v4-HoA option when it wants to remove the binding for v4 HoA? Or maybe the MN could set the v4-HoA and v4-CoA options to the same IP address? In this way MN would declare itself to be v4-wise at home and the HA would remove the v4 binding. I'm not sure if this second approach is applicable to PMIP.

domagoj

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of RYUJI WAKIKAWA
> Sent: 29. veljača 2008 18:01
> To: [email-masked]
> Subject: [MEXT] Fwd: [netlmm] comments 
> ondraft-ietf-netlmm-pmip6-ipv4-support-02
> 
> Hi Hesham,
> 
> I recently got comments from Premec about DSMIP support on PMIP.
> Some of comments are related to the base DSMIP spec.
> Original mail was attached below.
> 
> summary.
> 
> 1. When MN acquires a private IPv4 HoA and obtains a private 
> IPv4 CoA at a visited network,
>    both addresses can be same because of private space. This 
> may cause problem.
>    We should not allow the private home address.
> 
> 2. If MN wants to remove a binding only for IPv4 HoA, how can 
> MN de- register the binding?
>    If it sends a deregiatration BU, bindings of both IPv4 and 
> IPv6 HoAs are removed at the HA.
> 
> 3. There is no lease time for an IPv4 home address when MN 
> obtains it by BU/BA exchange.
>     Do we need lifetime field in the IPv4 address 
> acknowledgement option?
>     In MIPv6, HA gives the lease time for IPv6 home address
>      by the prefix information option carried by MPA and RA.
> 
> regards,
> ryuji
> Begin forwarded message:
> 
> > 差出人: RYUJI WAKIKAWA <[email-masked]>
> > 日時: 2008年3月1日 1:44:52:JST
> > 宛先: "Premec, Domagoj" <[email-masked]>
> > Cc: NetLMM List Mailing <[email-masked]>
> > 件名: 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)
> >
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
> 
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext