Subject: [netlmm] Some questions for draft-ietf-netlmm-pmip6-ipv4-support-03

From: Niklas Neumann <[email-masked]>
Date: Thu, 03 Jul 2008 15:36:31 +0200

Hello everybody,

I started doing a quick review of 
draft-ietf-netlmm-pmip6-ipv4-support-03 up to Section 3. I will continue 
with the rest of the document in the next days unless you already have 
enough feedback.
I can also help out a bit with grammar and phrasing if that is needed. 
In that case, please let me know what format you'd prefer (doc, rtf, 
txt-diff, ...).

Here are my questions so far:

1. Overview

IPv4 Home Address Mobility Support: A mobile node that has an IPv4 stack 
enabled will be able to obtain an IPv4 address and be able to use that 
address from any of the access networks in that Proxy Mobile IPv6 domain.
* Is it defined somewhere else or just implied that every access network 
in a PMIP domain is MAG-enabled?

IPv4 Transport Network Support: The mobility entities ...
* What are the mobility entities? MNs or MAGs/LMAs?
* In general I don't quite understand what this paragraph is supposed to 
say. You want to make clear that you do not need IPv6 running between 
the MAGs and the LMA?

1.1. Stated Assumptions

The mobile node's IPv4 home network prefix is a shared prefix (unlike 
its IPv6 home network prefix, which is a shared prefix).
* I don't get it. What is the difference here? You meant to say "unlike 
an IPv6 home network prefix, which is a unique prefix"?

There can be more than one mobile node sharing address(es) from the same 
IPv4 home network prefix.
* This means you can have duplicate IP addresses?

The mobile access gateway is always the IPv4 default-router for the 
mobile node on its access link. It will always be able to receive 
traffic sent to the mobile node's IPv4 default-router address.
* Maybe use MUST instead of "is always" and "will always" to emphasize 
directions.

2.2. Terminology

IPv4 Proxy Care-of Address: However, when the configured address is a 
private IPv4 address and with a NAT device in the path to the local 
mobility anchor, the care-of address as seen by the local mobility 
anchor will be the address allocated by the NAT device for that flow.
* Do you refer to a flow in particular? Maybe better say "... for a 
particular flow." And what are the implications of this? Especially for 
the Binding Cache, does the LMA update the BC for every new flow and 
hopes the NAT GW holds the pinhole open long enough?

3. IPv4 Home Address Mobility Support

If the mobile node connects to the Proxy Mobile IPv6 domain, [...] each 
of the connected interfaces will obtain an address from a unique IPv4 
home network prefix.
* How is this supposed to work? Especially since in 1.1. you stated that 
the home network prefixes are shared prefixes.

Further, when the mobile node [...] performs an inter-technology handoff
* Is it intended to get into inter-technology handoffs at this point?

3.1. IPv4 Home Address Assignment

Figure 2:
* I think it is more accurate to say that the DHCP discovery (no.1) and 
PBU (no.2) do not have any specific chronological order than to infer 
that they will be "operated in parallel".

Best regards
   Niklas

-- 
Niklas Neumann - University of Goettingen, Institute of Informatics
http://user.informatik.uni-goettingen.de/~nneuman1/
Tel: +49 551 39-14419
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 3 Jul 2008 10:35:42 -0700 (PDT)

Hi Niklas,

Thanks for the comments. We have fixed the nits that you have
pointed out in the latest rev, yet to be published. Its taking
bit more time to fix all the issues, but most of these comments
should go away. Please see inline for my responses.

Sri

On Thu, 3 Jul 2008, Niklas Neumann wrote:

> Hello everybody,
>
> I started doing a quick review of draft-ietf-netlmm-pmip6-ipv4-support-03 up 
> to Section 3. I will continue with the rest of the document in the next days 
> unless you already have enough feedback.
> I can also help out a bit with grammar and phrasing if that is needed. In 
> that case, please let me know what format you'd prefer (doc, rtf, txt-diff, 
> ...).
>
> * Is it defined somewhere else or just implied that every access network in a 
> PMIP domain is MAG-enabled?
>

That's implied. Sure, there needs to be a MAG function on every access
link.

> * In general I don't quite understand what this paragraph is supposed to say. 
> You want to make clear that you do not need IPv6 running between the MAGs and 
> the LMA?
>
>

Base spec clearly identifies the mobility entities, LMA and MAG.
W.r.t the transport, the LMA and MAG should be able to comminicate
using IPv4 addresses. Will reword it as required.

> 1.1. Stated Assumptions
>
> The mobile node's IPv4 home network prefix is a shared prefix (unlike its 
> IPv6 home network prefix, which is a shared prefix).
> * I don't get it. What is the difference here? You meant to say "unlike an 
> IPv6 home network prefix, which is a unique prefix"?
>

This is what we have currently:

The mobile node's IPv4 home network prefix is typically a shared
prefix.  There can be more than one mobile node sharing an address
from the same IPv4 home network prefix.

> There can be more than one mobile node sharing address(es) from the same IPv4 
> home network prefix.

Prefix is shared, not an address is shared. In the above text, if you
still the ambiguity, we will reword it.

> The mobile access gateway is always the IPv4 default-router for the mobile 
> node on its access link. It will always be able to receive traffic sent to 
> the mobile node's IPv4 default-router address.

This is not a normative text. We are generally explaining the functional
roles.

>
> 2.2. Terminology
>
> IPv4 Proxy Care-of Address: However, when the configured address is a private 
> IPv4 address and with a NAT device in the path to the local mobility anchor, 
> the care-of address as seen by the local mobility anchor will be the address 
> allocated by the NAT device for that flow.
> particular flow." And what are the implications of this? Especially for the 
> Binding Cache, does the LMA update the BC for every new flow and hopes the 
> NAT GW holds the pinhole open long enough?
>

This text is rewritten. You can look at the latest rev after we
publish and comment.

> If the mobile node connects to the Proxy Mobile IPv6 domain, [...] each of 
> the connected interfaces will obtain an address from a unique IPv4 home 
> network prefix.
> * How is this supposed to work? Especially since in 1.1. you stated that the 
> home network prefixes are shared prefixes.
>

A prefix is not for the exclusive use of a mobile node. More than one
mobile node can be configuring a unique address from the same prefix.
Now, for a mutihomed mobile node, as you would expect, each interface
will have a different address.

> * Is it intended to get into inter-technology handoffs at this point?

Need to check, if this comment is still valid, but I'd say even in
intro we will explaing the basic feature overview and inter-tech
handoff is a critical aspect of this.

> * I think it is more accurate to say that the DHCP discovery (no.1) and PBU 
> (no.2) do not have any specific chronological order than to infer that they 
> will be "operated in parallel".
>

Agree.

Please review the next rev, we will publish it in the next few days,
before the IETF last date.

Sri

---

From: Niklas Neumann <[email-masked]>
Date: Fri, 04 Jul 2008 14:14:21 +0200

Hi Sri,

thank you for your reply. I will wait with further comments until there 
is a new version of the document.

Just one further comment:

>> * I don't get it. What is the difference here? You meant to say 
>> "unlike an IPv6 home network prefix, which is a unique prefix"?
> 

I was referring to the second part of the sentence where you state that 
the IPv6 home network prefix is a shared prefix. I guess it's just a typo.

Have a nice weekend!

Best regards
   Niklas