Subject: [netlmm] Some minor comments on draft-ietf-netlmm-pmip6-ipv4-support-04.txt

From: "Mohana Jeyatharan" <[email-masked]>
Date: Thu, 4 Sep 2008 11:10:51 +0800

Hi Sri and Ryuji,

I read your draft recently. This draft has seen many comments.
Nevertheless I have few comments (editorial) and some minor
clarifications.

If the editorial comments are already closed pls ignore.
Thanks.

BR,
Mohana

In page 7, there is a minor typo error

->  Its is not for the exclusive use of any one mobile node.
      There can be more than one mobile node sharing different addresses
      from the same IPv4 subnet.

It should be "it is".

Another typo error in page 18 

->The bi-directional established with the local mobility anchor with
      IPv4 or IPv6 transport and using any of the supported
      encapsulation mode, as per [RFC-5213] or as per this specification
      when using IPv4 transport, MUST be enabled to carry IPv4 traffic.

It should be "bi-directional tunnel".

Another type error in pg 24
->Additional Operation:

   o  At an point the mobile access gateway fails to extend the binding
      lifetime with the local mobility anchor, it MUST send an
      unsolicited DHCPNACK to the mobile node.  It MUST also tear down
      the point-to-point link shared with the mobile node

The sentence should have been at "any point"

->3.4.2.  DHCP Relay Agent co-located with the Mobile Access Gateway

   A DHCP relay is co-located with each mobile access gateway.  A DHCP
   server is located somewhere in the Proxy Mobile IPv6 domain or is co-
   located with the local mobility anchor.  Figure 6 are the sequence of
   IPv4 home address assignment using DHCP Relay.

It should have been Figure 6 shows

Other comments and some clarifications:

(1)In page 8, it is mentioned that each of the interface will be given a
unique IPv4 HoA. I think this is applicable only for IPv4 hosts. For
dual stack hosts this can be optional. This is my general understanding
especially looking at some 3GPP activities. You can access a IPv4/v6 PDN
using multiple interfaces and perhaps get IPv4 HoA via one interface and
an IPv6 HoA via another interface. Perhaps, you are assuming all this is
associated with the policy and giving a generic description of IPv4
assignment similar to IPv6 assignment in RFC 5213.
Well, it is not a big issue but I was just wondering why it is stated as
"will get IPv4 address via each interface" in page 8 the last section...

(2)The prefix length for IPv4 address is stored in BL or policy profile?
When reading the draft it seems it is mentioned the policy profile has
this information. So, after PBU is sent will the binding list have this
information similar to the BC at LMA?

(3)In page 21 where the MAG acts as a DHCP server, I am not sure why
hardware address cannot be used as client identifier. Afetr vertcial
handoff, the PMIP mechanism will provide the correct IPv4 MN.HoA to the
target MAG and upon DHCP negotiation this address can be offered. I am
not sure why a unique client identifier similar to NAI or something like
that should be used. Perhaps you all have a valid reason for this....

(4)In page 22, it is mentioned that the DHCP offer message will either
have default router address or globally fixed address used for all DHCP
servers. But if MAG-LMA transport is IPv4 perhaps the MAG proxy CoA can
also be given. Or do you want to restrict to a generic case applicable
to all types of transport networks?

(5)When MAG is the DHCP server, are there any changes that the MN need
to have to obtain IPv4 address? When reading the draft, it seems there
may be some changes from network side to integrate DHCP and PMIP but not
from the MN. Am I right to say that? It should be so taking into account
of legacy support..

(6)In page 33, in the address format it is mentioned the destination
address will be IPv4-proxy-coa. Will it be so if MAG is behind the NAT.
I thought it should be NAT translated address?
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm