Subject: [netlmm] Working Group Last Call - draft-ietf-netlmm-pmip6-ipv4-support-05

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 6 Oct 2008 23:28:58 -0700

All,
This is a WG LC for the IPv4 support document.  Please review and send comments to the list by Oct 21, 2008.

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

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Tue, 14 Oct 2008 09:47:32 +0300

Hello everybody,

There is a week to go with this. If nobody comments, the draft is not going
to go forward. Please, read the draft and comment!

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 14 Oct 2008 13:40:23 +0200

Hi,

I support this document, it is needed since the IPv4 support is an essential part of the complete PMIP solution. Without this document, the RFC 5213 would be seriously limited in its applicability. I think the document is in fairly good shape and that it can be advanced. I'm re-sending here my recent comments on the -05 version, they can be considered as my comments for the WG last call.

domagoj

Comments:

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

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

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, will it leave HNP untouched... could you please add some text to clarify?

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

editorial:

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

"with respect" -> "with respect to"

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

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

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

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Narayanan, Vidya
> Sent: 07. listopad 2008 08:29
> To: [email-masked]
> Subject: [netlmm] Working Group Last Call 
> -draft-ietf-netlmm-pmip6-ipv4-support-05
> 
> All,
> This is a WG LC for the IPv4 support document.  Please review 
> and send comments to the list by Oct 21, 2008.
> 
> Thanks,
> Vidya

---

From: Teemu Rinta-aho <[email-masked]>
Date: Tue, 21 Oct 2008 14:36:16 +0300

Hi all,

there is the following paragraph in section 4, on page 30:

"The mobile access gateway can be potentially in a private IPv4
network behind a NAT [RFC-3022] device, with a private IPv4
address configured on its egress interface.  However, the local
mobility anchor must not be behind a NAT and must be using a
globally routable IPv4 address."

Does the LMA really need a *globally* routable IPv4 address?

BR,
Teemu Rinta-aho

-- 
Teemu Rinta-aho                    Tel: +358 9 299 3078
NomadicLab, Ericsson Research      Fax: +358 9 299 3535
Oy L M Ericsson Ab                 Mobile: +358 40 562 3066
FIN-02420 Jorvas, Finland          E-mail: [email-masked]
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Julien Laganier <[email-masked]>
Date: Fri, 31 Oct 2008 14:32:59 +0100

On Tuesday 07 October 2008, Narayanan, Vidya wrote:
> All,
> This is a WG LC for the IPv4 support document.  Please review and
> send comments to the list by Oct 21, 2008.

Sorry that I'm late, but anyway, I found this:

We agreed that by default no UDP encapsulation is used for signaling 
messages:

> 5.2. Mobile Access Gateway - Configuration Variables
>
> [...]
>
>    UseIPv4UDPEncapForSignalingMessages
>
>       This flag indicates whether or not the mobile access gateway
>       should use IPv4-UDP encapsulation mode for the signaling
>       messages.
>
>       The default value for this flag is set to value of 0,
>       indicating that the mobile access gateway MUST NOT use IPv4-UDP
>       encapsulation mode, but MUST use native IPv4 encapsulation mode
>       for sending the Proxy Mobile IPv6 signaling messages.
>
>       When the value for this flag is set to value of 1, the mobile
>       access gateway MUST use IPv4-UDP encapsulation mode for sending
>       the Proxy Mobile IPv6 signaling messages.

But then in multiple place the text hasn't been aligned with the 
introduction of this configuration variable. 

> 4.1.3.2. Constructing the Proxy Binding Acknowledgement Message
>
> [...]
> 
>   o  The NAT Detection option [ID-DSMIP6] MUST be present only if
>   there is a IPv4 Care-of Address option [ID-DSMIP6] present in the
>   received Proxy Binding Update and if the NAT detection procedure
>   resulted in detecting a NAT on path.  In all other cases, the
>   option MUST NOT be present.

The sentence should be changed to:

o  The NAT Detection option [ID-DSMIP6] MUST be present only if
   there is a IPv4 Care-of Address option [ID-DSMIP6] present in the
   received Proxy Binding Update and the Proxy Binding Update is 
   encapsulated in UDP, and if the NAT detection procedure 
   resulted in detecting a NAT on path.  In all other cases, the
   option MUST NOT be present.

> 4.1.3.3. NAT Presence Detection
>
>    When the transport network between the local mobility anchor and
>    the mobile access gateway is an IPv4 network, the mobile access
>    gateway will send the Proxy Binding Update messages encapsulated in
>    the IPv4- UDP packet. [...]

I think we should add this sentence before the fist paragraph: "If the 
UseIPv4UDPEncapForSignalingMessages flag is set to 0 (zero) then NAT 
Presence Detection is not performed. Otherwise, NAT Presence Detection 
is performed as follows."

Otherwise we're implying that the PBU is always sent encapsulated in 
IPv4-UDP which is in contradiction with the flag being set to zero...

> 4.2.2. Signaling Considerations
> 
> [...]
>
>      *  If there is a NAT Detection option [ID-DSMIP6] in the received
>         Proxy Binding Acknowledgement message, then the encapsulation
>         mode for the tunnel MUST be set to IPv4-UDP.  Otherwise the
>         encapsulation mode MUST be set to IPv4.

Same thing would apply here: We should change the sentence to:

      *  If the UseIPv4UDPEncapForSignalingMessages flag is set to 1 and 
         there is a NAT Detection option [ID-DSMIP6] in the received
         Proxy Binding Acknowledgement message, then the encapsulation
         mode for the tunnel MUST be set to IPv4-UDP.  Otherwise the
         encapsulation mode MUST be set to IPv4.

The case where the UseIPv4UDPEncapForSignalingMessages flag is set to 
zero and a NAT Detection option is received does not need to be covered 
since the option will never be present as per the first change I'm 
proposing.

--julien