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

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 3 Jul 2008 12:14:30 -0700 (PDT)

Hi Sri,
  Regarding home network prefixes typically shared in IPv4, I think that RFC 4903 on multi-link subnet issues applies to IPv4 as well.
  My suggestion is:
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.

to remove the above text, I thought the intent here was about private addresses and possibility of collision because of that. If that is not the case, being silent is a better choice.

Regards,

Behcet

----- Original Message ----
From: Sri Gundavelli <[email-masked]>
To: Niklas Neumann <[email-masked]>
Cc: [email-masked]
Sent: Thursday, July 3, 2008 12:35:42 PM
Subject: Re: [netlmm] Some questions for draft-ietf-netlmm-pmip6-ipv4-support-03

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

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

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

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.
> * This means you can have duplicate IP addresses?
>

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.
> * Maybe use MUST instead of "is always" and "will always" to emphasize 
> directions.
>

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

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

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

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.

> Further, when the mobile node [...] performs an inter-technology handoff
> * 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.

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

Agree.

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

Sri

>
> 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
>
>
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 3 Jul 2008 12:46:37 -0700 (PDT)

Hi Behcet,

We dont have the luxury to alloate a unique prefix for each mobile
node. That multiplies the address space requirement by 4 times.
4903 recommendation is primarily for IPv6. All though some of
the issues are applicable to IPv4, we cannot go the extreme of
allocating a prefix for each node. This is inline with 3344,
3344bis or DSMIP6.

> to remove the above text, I thought the intent here was about private
> addresses and possibility of collision because of that. If that is
> not the case, being silent is a better choice.

The intent is here not about address collision, its about the
supported addressing model, we cannot stay silent.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 3 Jul 2008 16:09:28 -0400

Agree.

Vijay

> >  Regarding home network prefixes typically shared in IPv4, I think
that
> RFC 4903 on multi-link subnet issues applies to IPv4 as well.
> >  My suggestion is:
> addresses and possibility of collision because of that. If that is not
the
> case, being silent is a better choice.
> >
> > Regards,
> >
> > Behcet
> >
> >
> > Subject: Re: [netlmm] Some questions for
draft-ietf-netlmm-pmip6-ipv4-
> support-03
> >> 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
> >> 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,
> >> * 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 mobile node's IPv4 home network prefix is a shared prefix
(unlike
> its
> >> * I don't get it. What is the difference here? You meant to say
"unlike
> an
> >> node on its access link. It will always be able to receive traffic
sent
> to
> >> 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
> >> 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
> >> If the mobile node connects to the Proxy Mobile IPv6 domain, [...]
each
> of
> >> * 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