Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-pmip6-ipv4-support-05.txt

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 16 Oct 2008 22:05:44 -0700

Hi Domagoj,
 
Sorry for the late reply, out of town, to most part.
 
Please see inline.
 
Regards
Sri

________________________________

From: Premec, Domagoj [mailto:[email-masked]]
Sent: Tue 9/30/2008 8:23 AM
To: Sri Gundavelli (sgundave); RYUJI WAKIKAWA
Cc: [email-masked]
Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-pmip6-ipv4-support-05.txt

Hi Sri, Ryuji,

I read the draft and I think it is in a good shape, please find some comments below:

- use of unsolicited DHCPNACK
At couple of places the draft requires the MAG to send unsolicited DHCPNACK to revoke the IPv4 HoA from the MN.  However, as far as I know this is not compliant with the DHCPv4 RFCs. The regular DHCPv4 client will simply ignore such unsolicited DHCPNACK and nothing will happen. The only way to revoke the IPv4 address via DHCPv4 is to use FORCERENEW.

[Sri] The draft lists both the options, the use of FORCERENEW and Unsolicited NACK. Both the mechanisms can be used. The client may ignore the unsolicited DHCPNACK. but it is not a MUST that it should ignore that, but will check 2131 and the related docs. Additionally, will clarify this point and not mandate on one approach.

- DHCPRELEASE
The description of the DHCPRELEASE message triggering the MAG to send the PBU with lifetime of zero for the IPv4 HoA is still missing. IMO it would be good to have a text along the following lines as part of the draft:

[Sri] The PMIP dereg procedures with respect of IPv4 session are clearly specified, we need to add few lines on the potential triggers, trigger from a RADIO network or an explicit DHCP address release.

3.4.3 DHCP Release

The mobile node may release its IPv4 home address at any time by sending the DHCPRELEASE message [RFC-2131]. When the MAG detects the DHCPRELEASE message sent by the mobile node and containing the mobile node's IPv4 home address, the MAG SHALL de-register the mobile node's IPv4 home address with the LMA. The MAG SHALL send the Proxy Binding Update message containing the IPv4 Home Address option set to the mobile node's IPv4 home address and the lifetime SHALL be set to zero. The Proxy Binding Update message SHALL NOT contain the Home Network Prefix option. The LMA SHALL remove the IPv4 home address from the binding cache entry and respond to the MAG with the Proxy Binding Acknowledgment message indicating success. If there was no IPv6 Home Network Prefix registered for the mobile node, the LMA and MAG SHALL remove their binding cache and binding update list entries for the mobile node. If the binding cache entry contains the IPv6 Home Network Prefix registered for the mobile node, the IPv6 Home Network Prefix and its lifetime remain unaffected by such Proxy Binding Update message.

[Sri] This sounds good. Will clarify to this affect.

When reading the draft I couldn't find an answer to following question: assuming the BCE contains both the HNP and IPv4 HoA and the MAG sends the PBU containing only the IPv4 HoA (but no HNP), what is the behaviour? Will the LMA reject such PBU, will it extend the lifetime of the IPv4 HoA and remove the HNP from the BCE... could you please add some text to clarify?

[Sri] We did cover selective dereg procedure of IPv4 or IPv6 session termination. Few lines on this below. However, will review and clarify.

"However, if the request is for a selective  de-registration (IPv4-only or IPv6-only addresses), the Binding Cache
   entry MUST not be deleted, only the respective states with respect those addresses MUST be deleted."

- anti-spoofing check by MAG
Would it make sense to require the MAG to do an anti-spoofing check for the MN's IPv4 HoA before tunneling packets to the LMA? This would make sure that the MAG and the MN are in sync about the MN's IPv4 HoA and is of relevance for cases where the MN obtains its IPv4 HoA via other means (static, IPCP or any other link-layer specific mechanism...)

[Sri] Its too implicit I thought. The IPv4 policy route for a given HoA exists only if there is an established session for that MN. In all cases, the general ingress filtering rules of unauthorised source address usage should apply.

editorial:

3.1.2.5
> [...] only the respective states with respect
> those addresses [...]

"with respect" -> "with respect to"

[Sri] Ok

3.2.3.3
"exactly one instance if" -> "exactly one instance of"

[Sri] Ok

>   o  If there is an IPv4 Default-Router Address option present in the
>      received Proxy Binding Acknowledgement message, the mobile access
>      gateway MAY configure this address on its interface and respond to
>      any ARP requests sent by the mobile node for resolving the
>      hardware address of the default-router.

Maybe the following sentence could be added:
"When the ARP is not used on the link between the mobile access gateway and the mobile node, the mobile access gateway MAY use the IPv4 Default-Router-Address as the source address for any datagrams sent to the mobile node and originated by the mobile access gateway itself. The mobile access gateway MAY use the IPv4 Default-Router-Address to fill in the DHCP Router option [RFC-2132]."

This should be fine

3.4.1
>   [...] that is on co-
>   located on [...]
remove the first "on"

[Sri] Ok

domagoj

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 23. rujan 2008 10:15
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netlmm] I-D
> Action:draft-ietf-netlmm-pmip6-ipv4-support-05.txt
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Network-based Localized
> Mobility Management Working Group of the IETF.
>
>
>       Title           : IPv4 Support for Proxy Mobile IPv6
>       Author(s)       : R. Wakikawa, S. Gundavelli
>       Filename        : draft-ietf-netlmm-pmip6-ipv4-support-05.txt
>       Pages           : 47
>       Date            : 2008-09-23
>
> This document specifies extensions to Proxy Mobile IPv6
> protocol for adding IPv4 protocol support.  The scope of IPv4
> protocol support is
> two-fold: 1) extending IPv4 home address mobility support to
> the mobile node. 2) allowing the mobility entities in the Proxy Mobile
> IPv6 domain to exchange signaling messages over an IPv4
> transport network.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ip
> v4-support-05.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail
> reader implementation to automatically retrieve the ASCII
> version of the Internet-Draft.
>

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

---

From: Shi Xiaoyan <[email-masked]>
Date: Mon, 20 Oct 2008 20:24:14 +0800

Hi Sri, Ryuji,
 
Some comments below:
 
-- About Looking up BCE.
In section 3.1.2.1.
      *  If there is at least one instance of the Home Network Prefix
         option [RFC-5213] with a NON_ZERO prefix value, or, if there is
         an IPv4 Home Address option [ID-DSMIP6] with the IPv4 address
         in the option set to ALL_ZERO, considerations from Section
         5.4.1 of [RFC-5213] MUST be applied.
 
      *  If there is an IPv4 Home Address option [ID-DSMIP6] present in
         the request with the IPv4 address value in the option set to a
         NON_ZERO value, considerations from Section 3.1.2.7 MUST be
         applied.
>From section 3.1.2.1, when LMA recieves PBU with IPv4 Home Address
option(ALL_ZERO) and without HNP, it can be concluded that considerations
from Section 5.4.1 of [RFC-5213] MUST be applied, But there is not a
description for IPv4 address look up in RFC5213.
 
According to my understanding, IPv6 prefix is prior to IPv4 address to look
up BCE. This means
    If Home Network Prefix option with NON_ZERO in PBU, IPv6 prefix should
be used to look up BCE.
    If all Home Network Prefix option with NON_ZERO in PBU and IPv4 home
address with NON_ZERO, IPv4 address should be used to look up BCE.
    If all Home Network Prefix option with NON_ZERO in PBU and IPv4 home
address with ZERO, considerations from RFC5213 should be applied.
    If no Home Network Prefix option in PBU and IPv4 home address with ZERO
or NON_ZERO, considerations from section 3.1.2.7 should be applied.
 
I think there should be some modification for correct looking up.
 
--How LMA to deal with HNP in PBU match that in BCE but IPv4 address does
not match?
The PBU is accepted or rejected? If the PBU is rejected, state coede in PBA
is NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS or to define a new code?

 
Regards,
Xiaoyan

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sri Gundavelli (sgundave)
Sent: Friday, October 17, 2008 1:06 PM
To: Premec, Domagoj; RYUJI WAKIKAWA
Cc: [email-masked]
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-pmip6-ipv4-support-05.txt

Hi Domagoj,

Please see inline.
 
Regards
Sri

  _____  

Hi Sri, Ryuji,

I read the draft and I think it is in a good shape, please find some
comments below:

- use of unsolicited DHCPNACK
At couple of places the draft requires the MAG to send unsolicited DHCPNACK
to revoke the IPv4 HoA from the MN.  However, as far as I know this is not
compliant with the DHCPv4 RFCs. The regular DHCPv4 client will simply ignore
such unsolicited DHCPNACK and nothing will happen. The only way to revoke
the IPv4 address via DHCPv4 is to use FORCERENEW.

[Sri] The draft lists both the options, the use of FORCERENEW and
Unsolicited NACK. Both the mechanisms can be used. The client may ignore the
unsolicited DHCPNACK. but it is not a MUST that it should ignore that, but
will check 2131 and the related docs. Additionally, will clarify this point
and not mandate on one approach.

- DHCPRELEASE
The description of the DHCPRELEASE message triggering the MAG to send the
PBU with lifetime of zero for the IPv4 HoA is still missing. IMO it would be
good to have a text along the following lines as part of the draft:

[Sri] The PMIP dereg procedures with respect of IPv4 session are clearly
specified, we need to add few lines on the potential triggers, trigger from
a RADIO network or an explicit DHCP address release.

3.4.3 DHCP Release

The mobile node may release its IPv4 home address at any time by sending the
DHCPRELEASE message [RFC-2131]. When the MAG detects the DHCPRELEASE message
sent by the mobile node and containing the mobile node's IPv4 home address,
the MAG SHALL de-register the mobile node's IPv4 home address with the LMA.
The MAG SHALL send the Proxy Binding Update message containing the IPv4 Home
Address option set to the mobile node's IPv4 home address and the lifetime
SHALL be set to zero. The Proxy Binding Update message SHALL NOT contain the
Home Network Prefix option. The LMA SHALL remove the IPv4 home address from
the binding cache entry and respond to the MAG with the Proxy Binding
Acknowledgment message indicating success. If there was no IPv6 Home Network
Prefix registered for the mobile node, the LMA and MAG SHALL remove their
binding cache and binding update list entries for the mobile node. If the
binding cache entry contains the IPv6 Home Network Prefix registered for the
mobile node, the IPv6 Home Network Prefix and its lifetime remain unaffected
by such Proxy Binding Update message.

When reading the draft I couldn't find an answer to following question:
assuming the BCE contains both the HNP and IPv4 HoA and the MAG sends the
PBU containing only the IPv4 HoA (but no HNP), what is the behaviour? Will
the LMA reject such PBU, will it extend the lifetime of the IPv4 HoA and
remove the HNP from the BCE... could you please add some text to clarify?

[Sri] We did cover selective dereg procedure of IPv4 or IPv6 session
termination. Few lines on this below. However, will review and clarify.

"However, if the request is for a selective  de-registration (IPv4-only or
IPv6-only addresses), the Binding Cache
   entry MUST not be deleted, only the respective states with respect those
addresses MUST be deleted."

- anti-spoofing check by MAG
Would it make sense to require the MAG to do an anti-spoofing check for the
MN's IPv4 HoA before tunneling packets to the LMA? This would make sure that
the MAG and the MN are in sync about the MN's IPv4 HoA and is of relevance
for cases where the MN obtains its IPv4 HoA via other means (static, IPCP or
any other link-layer specific mechanism...)

[Sri] Its too implicit I thought. The IPv4 policy route for a given HoA
exists only if there is an established session for that MN. In all cases,
the general ingress filtering rules of unauthorised source address usage
should apply.

editorial:

3.1.2.5

[Sri] Ok

3.2.3.3

[Sri] Ok

Maybe the following sentence could be added:
"When the ARP is not used on the link between the mobile access gateway and
the mobile node, the mobile access gateway MAY use the IPv4
Default-Router-Address as the source address for any datagrams sent to the
mobile node and originated by the mobile access gateway itself. The mobile
access gateway MAY use the IPv4 Default-Router-Address to fill in the DHCP
Router option [RFC-2132]."

This should be fine

3.4.1
remove the first "on"

[Sri] Ok

domagoj

---

From: Shi Xiaoyan <[email-masked]>
Date: Mon, 20 Oct 2008 20:32:58 +0800

Sorry, there are some typo in last email,the description should be:
 
According to my understanding, IPv6 prefix is prior to IPv4 address to look
up BCE. This means
    If Home Network Prefix option with NON_ZERO in PBU, IPv6 prefix should
be used to look up BCE.
    If all Home Network Prefix option with ZERO in PBU and IPv4 home address
with NON_ZERO, IPv4 address should be used to look up BCE.
    If all Home Network Prefix option with ZERO in PBU and IPv4 home address
with ZERO, considerations from RFC5213 should be applied.
    If no Home Network Prefix option in PBU and IPv4 home address with ZERO
or NON_ZERO, considerations from section 3.1.2.7 should be applied.

Regards,
Xiaoyan

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shi Xiaoyan
Sent: Monday, October 20, 2008 8:24 PM
To: 'Sri Gundavelli (sgundave)'; 'RYUJI WAKIKAWA'
Cc: [email-masked]
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-pmip6-ipv4-support-05.txt

Hi Sri, Ryuji,
 
Some comments below:
 
-- About Looking up BCE.
In section 3.1.2.1.

 

 

 
 
Regards,
Xiaoyan

  _____  

Hi Domagoj,

Please see inline.
 
Regards
Sri

  _____  

Hi Sri, Ryuji,

- DHCPRELEASE

3.4.3 DHCP Release

editorial:

3.1.2.5

[Sri] Ok

3.2.3.3

[Sri] Ok

This should be fine

3.4.1
remove the first "on"

[Sri] Ok

domagoj

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 20 Oct 2008 17:23:15 +0200

Hi Sri,

>> At couple of places the draft requires the MAG to send unsolicited
>>  DHCPNACK to revoke the IPv4 HoA from the MN.  However, as far as 
>> I know this is not compliant with the DHCPv4 RFCs. The regular DHCPv4
>>  client will simply ignore such unsolicited DHCPNACK and nothing will happen. 
>> The only way to revoke the IPv4 address via DHCPv4 is to use FORCERENEW.
>	
>
> [Sri] The draft lists both the options, the use of FORCERENEW 
> and Unsolicited NACK. Both the mechanisms can be used. The client 
> may ignore the unsolicited DHCPNACK. but it is not a MUST that it should
> ignore that, but will check 2131 and the related docs. Additionally, will clarify 
> this point and not mandate on one approach.

RFC 2131 is clear that the DHCPNACK received during the BOUND state is discarded.

domagoj

	From: Sri Gundavelli (sgundave) [mailto:[email-masked]] 
	Sent: 17. listopad 2008 07:06
	To: Premec, Domagoj; RYUJI WAKIKAWA
	Cc: [email-masked]
	Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-pmip6-ipv4-support-05.txt

	Hi Domagoj,

	Please see inline.
	 
	Regards
	Sri

	Hi Sri, Ryuji,

	- DHCPRELEASE

	3.4.3 DHCP Release

	editorial:
	
	3.1.2.5

	[Sri] Ok

	3.2.3.3

	[Sri] Ok

	This should be fine
	
	3.4.1
	remove the first "on"

	[Sri] Ok

	domagoj