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

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 19 Feb 2008 16:24:03 +0100

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

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.

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.

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?

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.

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?)

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.

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.

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.

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?

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. 

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

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

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.

regards
domagoj
_______________________________________________
netlmm mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/netlmm

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Sat, 1 Mar 2008 01:44:52 +0900

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.

> 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

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

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

> "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
> "However, since Proxy Mobile IPv6 supports also IPv4-only nodes,  
> IPv6 home address is not always available on the terminal."
>
> 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.

> 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