Subject: [netlmm] Comments/Questions on IPv4 support

From: Julien Laganier <[email-masked]>
Date: Wed, 12 Nov 2008 11:55:30 +0100

Folks,

I have some comments/questions on the IPv4 support doc:

4.2.2. Signaling Considerations

    The mobile access gateway when sending a Proxy Binding Update message
    to the local mobility anchor MUST construct the message as specified
    in Section 6.9.1.5.  However, if the mobile access gateway is in an

=> Section 6.9.1.5 is in RFC5213.

    IPv4-only access network, the following additional considerations
    MUST be applied.

    o  The Proxy Binding Update message MUST be encapsulated in an IPv4
       packet.  However, if the value of the configuration variable,
       UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy
       Binding Update message MUST be encapsulated in an UDP header of an
       IPv4 packet.

    o  The IPv4 Care-of Address option [ID-DSMIP6] MUST be present.  The
       IPv4 address in the option MUST be set to the mobile access
       gateway's IPv4-Proxy-CoA.

    o  The packet MUST be constructed as specified in Section 4.2.3.

=> There's Section 4.2.3. in this document. Probably you mean 4.2.2.1.

[...]

4.2.2.1. Constructing the Proxy Binding Update Message

    o  The source address in the IPv4 header MUST be set to IPv4-Proxy-
       CoA of the mobile access gateway and the destination address MUST
       be set to the local mobility anchor's IPv4-LMAA.

    o  The IPv4 Care-of Address option [ID-DSMIP6] MUST be present.  The
       address MUST be set to the mobile access gateway's IPv4-Proxy-CoA.

    o  If the configuration variable ForceIPv4UDPEncapsulationSupport is
       set to value of 1, then the (F) flag in the Proxy Binding Update
       message MUST be set to value of 1.

    o  If the mobile access gateway and the local mobility anchor are
       using globally routable IPv4 addresses and if there is a security
       associated that is based of IPv4 addresses, then the encapsulated
       IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement
       message) MUST be protected using IPsec ESP [RFC-4301] mode and
       additionally there is no need to apply ESP header on the IPv6
       packet.  In all other cases, the Proxy Binding Update message MUST
       be protected on the IPv6 packet of the Proxy Binding Update
       message, prior to the IPv4 encapsulation.

    o  The format of the Proxy Binding Update message encapsulated in an
       IPv4 or IPv4-UDP packet with no IPsec protection:

        IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
           UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/
              /* IPv6 PBU Packet protected with ESP header */

       Figure 11: Proxy Binding Update (PBU) message encapsulated in IPv4
                                   UDP header

    o  The format of the Proxy Binding Update message encapsulated in an
       IPv4 UDP packet and with IPsec protection on the encapsulated
       packet:

        IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
           ESP Header
              UDP header (sport=ANY, dport= DSMIP_PORT)  /*Optional*/
                 /* IPv6 PBU Packet protected with no ESP header */

       Figure 12: Proxy Binding Update (PBU) message encapsulated in IPv4
                                   ESP header

=> Reading all of that, I understand that the full packet sent on the
wire will be either of:

- IPv4 [UDP] IPv6 MH
- IPv4 ESP [UDP] IPv6 MH

If my understanding is correct, I'm wondering what source and
destination IPv6 addresses are to be used in the IPv6 header... AFAICS
that is unspecified.

--julien

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 12 Nov 2008 07:36:48 -0800

Hi Julien,

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Wednesday, November 12, 2008 2:56 AM
> To: [email-masked]; 
> [email-masked]
> Subject: Comments/Questions on IPv4 support
> 
> Folks,
> 

Ok. Thanks

> destination IPv6 addresses are to be used in the IPv6 header... AFAICS

The source should the Proxy-CoA and the destination LMAA as the inside
headers of the IPv6 packet.

On time, will update this.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Nov 2008 04:03:31 +0100

> headers of the IPv6 packet.

I thought the IPv4 transport was addressing the scenario where neither 
the MAG nor the LMA have IPv6 addresses (If both the MAG and LMA have 
IPv6 addresses, they can simply use native IPv6 to send the PBU or PBA). 
How do we handle that case? Could we specify the use of IPv4-Mapped IPv6 
Address in the IPv6 header?

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 12 Nov 2008 19:35:21 -0800 (PST)

On Thu, 13 Nov 2008, Julien Laganier wrote:

> I thought the IPv4 transport was addressing the scenario where neither the 
> MAG nor the LMA have IPv6 addresses (If both the MAG and LMA have IPv6 
> addresses, they can simply use native IPv6 to send the PBU or PBA). How do we 
> handle that case? Could we specify the use of IPv4-Mapped IPv6 Address in the 
> IPv6 header?
>

There could be two IPv6 islands connected by an IPv4 internet, the
common case. In this case, the transport is still IPv4. The src
and destination addresses are just as configured. For the other
case of no IPv6 on the MAG, which is not the assumption of the
draft. The MAG needs to have an IPv6 address and its just a detail
on how the MAG configures that address. In most cases thats a mapped
address. We thought that need not be specified.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Nov 2008 07:51:43 +0100

Sri Gundavelli wrote:
>>> >  [...] > >  => Reading all of that, I understand that the full 
>>> packet sent on the
>>> >  wire will be either of:
>>> > >  - IPv4 [UDP] IPv6 MH
>>> >  - IPv4 ESP [UDP] IPv6 MH
>> IPv6 addresses, they can simply use native IPv6 to send the PBU or 
>> PBA). How do we handle that case? Could we specify the use of 
>> IPv4-Mapped IPv6 Address in the IPv6 header?
>>
> 

Without questioning the value of scenario you're outlining above...

Are you saying the draft does not support a scenario where neither the 
MAG nor the LMA have IPv6 addresses?

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 12 Nov 2008 23:18:51 -0800 (PST)

On Thu, 13 Nov 2008, Julien Laganier wrote:

> Are you saying the draft does not support a scenario where neither the MAG 
> nor the LMA have IPv6 addresses?
>

Not sure, why that scenario is any different or cant be supported.
Assumption, MAG has an IPv6 stack. It is able to send and receive
PMIPv6 control messages. Now, when the transport is IPv4, the
source and destination addresses in the IPv4 header are the fields
used for packet delivery. The inside addresses in the IPv6 PBU
can be very well an IPv4-mapped IPv6 addresses or configured IPv6
addresses. These addresses are not used for routing in this context,
but as the peer identifier for IPsec. With out the IPv6 address
configuration, how can we send a PBU ? MIP header in IPv4 packet ?
Why is the IPv6 address configuration an issue ? It is possible
to make the IPv6 header irrelevant, but, I dont see why that would
be required. The document has the stated assumption, MAG and LMA
are IPv6 elements, signaling is IPv6, transport is IPv4, LMA and
MAG have IPv6 configured addresses. Its not requiring IPv6 transport
in the access network, its just about enabling IPv6 address config
on the egress interface. Where is the problem ?

Sri

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Nov 2008 09:06:43 +0100

> on the egress interface. Where is the problem ?

Well, how all of this would work if the MAG and/or LMA do not have 
global unicast IPv6 addresses wasn't all that clear to me. If 
IPv4-mapped IPv6 addresses are to be used when the MAG and/or LMA do not 
have global IPv6 addresses, I think that can be called out explicitly in 
the draft...

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 13 Nov 2008 00:09:47 -0800 (PST)

On Thu, 13 Nov 2008, Julien Laganier wrote:

>
> Well, how all of this would work if the MAG and/or LMA do not have global 
> unicast IPv6 addresses wasn't all that clear to me. If IPv4-mapped IPv6 
> addresses are to be used when the MAG and/or LMA do not have global IPv6 
> addresses, I think that can be called out explicitly in the draft...
>

Ok. We can add few lines on the need for configured IPv6 address and
its primary purpose and that these could be IPv4-mapped addresses ...

Sri

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 14 Nov 2008 01:58:32 +0900

Hi Julien and Sri,

We have following texts in the draft.

In Section 1.1, 
"The local mobility anchor and the mobile access gateway are both
IPv4 and IPv6 enabled.  Irrespective of the type of transport
network (IPv4 or IPv6) separating these two entities, the mobility
signaling is always based on Proxy Mobile IPv6 "

In section 4, 
"The local mobility anchor and the mobile access gateway are both
configured and reachable using an IPv4 address.  Additionally, both
entities are also IPv6 enabled and have configured IPv6 addresses on
their interfaces, as specified in [RFC-5213], but are reachable only
over an IPv4 transport."

Although I agree to add more clarification what IPv6 address is
configured to MAG/LMA, I am not sure we recommend IPv4-mapped address
here. Shall we just recommend to assign a routable IPv6 address
(regardless of global or not) to MAG/LMA?

regards,
ryuji

At Thu, 13 Nov 2008 09:06:43 +0100,

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 13 Nov 2008 09:42:54 -0800 (PST)

Hi Ryuji,

> (regardless of global or not) to MAG/LMA?

Probably our stated assumptions are sufficient. We just require the MAG
to have an IPv6 address. This can be a very well from a IPv6 prefix
block for all MAG's. I see your concern with any recommendations on
mapped addresses, from the DSMIP discussions. So, we can probably leave
it with some clarifications as needed in some places, related to IPv6
packet headers as Julien pointed, but not getting into the details on
using of mapped addresses instead.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Fri, 14 Nov 2008 02:08:53 +0100

Hi Ryuji,

> (regardless of global or not) to MAG/LMA?

If MAG and LMA are assigned a routable IPv6 address, that seems to 
contradict the last statememt of the paragraph you're quoting taht says 
MAG and LMA "are reachable only over an IPv4 transport". If they have 
routable IPv6 address, why aren't they reachable.

I think it makes sense to specify the use of IPv4-mapped addresses for 
some of the usage scenarios.

Regards,

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 13 Nov 2008 18:22:33 -0800 (PST)

Hi Julien,

On Fri, 14 Nov 2008, Julien Laganier wrote:

>
> If MAG and LMA are assigned a routable IPv6 address, that seems to contradict 
> the last statememt of the paragraph you're quoting taht says MAG and LMA "are 
> reachable only over an IPv4 transport". If they have routable IPv6 address, 
> why aren't they reachable.
>
> I think it makes sense to specify the use of IPv4-mapped addresses for some 
> of the usage scenarios.
>

The configured address on the MAG need not be routable. There can
be an IPv6 prefix block from where all the MAG's in the network
be given IPv6 addresses and with no reachability setup. The above
statement of reachability over IPv4 transport should not conflict
with this. We cant really stop one from configuring a 6to4 address
or other mapped address, as long as that address meets the global
uniquness requirement we should be fine from our perspective. But,
we dont have to suggest mapped address configuration, and where
there is better alternative of reserving a small block of IPv6
address for all the MAG's use. If you remember the DSMIP discussions,
on the mapped addresses, we can probably avoid that here.  If your
concern is that, globally unique address implies reachability, we can
clarify that.

Sri