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

From: Sri Gundavelli <[email-masked]>
Date: Wed, 3 Sep 2008 22:25:09 -0700 (PDT)

Hi Mohana,

Thanks for the review comments. Please see inline ..

On Thu, 4 Sep 2008, Mohana Jeyatharan wrote:

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

Some of these are taken care of after Charlie's and other
review comments. Will fix any new issues from your review.

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

Sure. A dual-stack node can certainly obtain both IPv6 and IPv4 addresses
and as you say, certainly a node can obtain IPv4-only address on one
interface and IPv6-only address on a different interface. All that
flexibility exists, May be the wording which is not clear, will check
this.

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

The IPv4 HoA that is assigned by the LMA has the prefix length, this
is obtained from the PBA. So, the BUL entry will have it. In cases,
where the MAG provides a hint (LMA may or may not honour), the MAG
would have both the address/prefix length at the time of sending
the PBU. However, till the BU is accepted, the address is not assigned
to the mobile.

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

Hope so.
If there is no inter-tech handoffs, hardware address is sufficient.
However, for supporting inter-tech handoffs, the DHCP binding cannot
be tied to a specific interface, as it may be moved in between interfaces.

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

It can be a Proxy-CoA. Will review this.

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

No changes are required to MN. Some editorial errors are there, took
care of them. No MN changes are required for supporting DHCP.

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

Sure. This is clarified in teminology section. From the LMA perspective,
the registered address is the CoA and this can be potentially a NAT
translated address.

Thanks again for the review. Will post the updated doc addressing
these comments.

Regards
Sri
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Thu, 4 Sep 2008 13:38:21 +0800

Hi Sri,

Please see reply in-line.

BR,
Mohana 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sri Gundavelli
> Sent: Thursday, September 04, 2008 1:25 PM
> To: Mohana Jeyatharan
> Cc: [email-masked]
> Subject: Re: [netlmm] Some minor comments 
> ondraft-ietf-netlmm-pmip6-ipv4-support-04.txt
> 
> Hi Mohana,
> 

Ok, I thought as much since Charlie already given a thorough review.

> > (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...
> >
> >
> 
> Sure. A dual-stack node can certainly obtain both IPv6 and 
> IPv4 addresses and as you say, certainly a node can obtain 
> IPv4-only address on one interface and IPv6-only address on a 
> different interface. All that flexibility exists, May be the 
> wording which is not clear, will check this.
> 
> 
> 
> > this information. So, after PBU is sent will the binding list have 
> > this information similar to the BC at LMA?
> >
> 
> The IPv4 HoA that is assigned by the LMA has the prefix 
> length, this is obtained from the PBA. So, the BUL entry will 
> have it. In cases, where the MAG provides a hint (LMA may or 
> may not honour), the MAG would have both the address/prefix 
> length at the time of sending the PBU. However, till the BU 
> is accepted, the address is not assigned to the mobile.

Ok, I understand now. Policy profile can have this info, but as you say,
Until PBA is received BL cannot be created at MN.
> > 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....
> >
> 
> Hope so.
> However, for supporting inter-tech handoffs, the DHCP binding 
> cannot be tied to a specific interface, as it may be moved in 
> between interfaces.
> 
Ok, can agree.
> > 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?
> >
> 

Thanks.
> > 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..
> >
> 
> No changes are required to MN. Some editorial errors are 
> there, took care of them. No MN changes are required for 
> supporting DHCP.
> 
> Sure. This is clarified in teminology section. From the LMA 
> perspective, the registered address is the CoA and this can 
> be potentially a NAT translated address.

> Thanks again for the review. Will post the updated doc 
> addressing these comments.
No, problem.