Subject: [nemo] Fw: [Mip6] Issue 66: Setting up forwarding for IPv4 HoA

From: Thierry Ernst <[email-masked]>
Date: Fri, 6 Oct 2006 11:33:34 +0200

This is for your information. The discussion has been launched on the
MIP6 ML, so you would better comment on the MIP6 ML if you have any.

Thierry

Begin forwarded message:

Date: Thu, 5 Oct 2006 17:42:57 +0200
From: "GRIMAULT Jean-Luc RD-CORE-CAE" <[email-masked]>
To: <[email-masked]>
Subject: [Mip6] Issue 66: Setting up forwarding for IPv4 HoA

Hello,

In DSMIPv6, I wonder if the requirement "the home agent MUST create two separate binding cache entries, one for each home address" (IPv6 home address and IPv4 home address) might not be misleading because of mobile Network prefixes. 

Logically in the HA's Binding cache, mobile network prefixes are bound to the IPv6 home address. The (IPv6 or IPv4) Care of address is also bound to the IPv6 home address. 

If it occurs that the Mobile Router has also an IPv4 home address (for its own IPv4 applications), the requirement for two separate binding cache entries, one for each home address, may imply that all (IPv6 and IPv4) mobile network prefixes need to be bound in the HA's binding cache to the IPv6 home address entry *and* also to the IPv4 home address entry. 

Firstly it may not be adequate because it implies  data duplication in the binding cache (especially when the MR serves many mobile network prefixes). Secondly, there is a doubt on what entry is used to forward the packets towards a mobile node served by the MR.   

More generally that may raise questions relative to the relationship between the IPv4 home address and the mobile network prefixes. 

For example, if the HA receives a BU with the IPv6 home address, the IPv4 home address, and mobile network prefixes included in the BU message (explicit mode in NEMO) and later the HA receives a new BU with the IPv6 home address and mobile network prefixes but without the IPv4 home address, the consequence on the IPv4 home address cache entry might be unclear. 

Another example is the position of the IPv4 home address with regard to the prefix table quoted in § 6.1.2 of NEMO Basic support; this may be unclear because § 6.1.2 quotes only "Home Address" and not "IPv6 Home Address" or "IPv4 Home Address". Another example is in § 6.2 NEMO BS : "If the Lifetime specified in the Binding Update is 0 or the specified Care-of Address matches the Home Address in the Binding Update .." ; in this case which Home Address; IPv4 or IPv6 ?

To solve these issues, is it not conceivable to state in the text of DSMIPv6 that, in case of a Mobile Router, the mobile network prefixes (IPv6 and IPv4) are bound uniquely to the IPv6 home address entry in the binding cache and that they are independent of the IPv4 home address?

Jean-Luc

================================================================================

Mip6] Issue 66: Setting up forwarding for IPv4 HoA

Issue text:

-----------

we shouldnt have specific language about creating

a binding cache entry for the IPv4 HoA. The language

should suggest setting up forwarding for the traffic

meant for the IPv4 HoA over the mip6trans tunnel.

Pascal responded:

Do you mean a second BCE? I thought that the idea was to have a single

BCE, indexed by the IPv6 HoA, and then allow to register various things

against that BCE, including addresses and prefixes from both AFs, and

maybe later DNS names and more...

Vijay responded:

 Vijay: the current drafts suggests a BCE for the IPv4

        HoA in addition to BCE for the IPv6 HoA.

        >I thought that the idea was to have a single

        >BCE, indexed by the IPv6 HoA, and then allow to register

various things

        >against that BCE, including addresses and prefixes from both

AFs, and

        >maybe later DNS names and more...

 Vijay: I agree. but thats no what is there in version 00.

        it explicity talks about a BCE for the IPv4 HoA.

Analysis:

---------

Several IETF specifications describe conceptual data as part of

documenting a protocol. This is typically done for additional

clarification. Examples of such specifications include IPsec, ND, and

MIP (v4 and v6). MIPv6 described the binding cache as a mechanism for

storing bindings. However, this does not in anyway force implementers to

implement MIPv6 exactly as described in the document, as long as the

external behaviour is consistent with the specification. Since this

specification is an extension to MIPv6, it is appropriate to describe

the conceptual data structure in a manner consistent with RFC 3775. 

RFC 3775 maintains that there is a separate Binding Cache entry for each

home address. As we are extending MIPv6 to support another address

family (IPv4), we still maintain the same philosophy of one binding

cache entry per home address, regardless of the type of HoA. 

Similar to MIPv6, this does not require implementers to do it exactly in

this manner, hence the term "conceptual data structure". One may choose

to implement the v4 entry in the routing table for instance (the same

can be said for the v6 entry). But in all cases, the entries will need

to be maintained (refreshed/deleted ...etc) as per the BU. 

Conclusion:

-----------

Keeping with the conceptual data structures in MIPv6 makes the spec

clear and does not limit implementers. There is no harm or bugs

introduced by the current text. Therefore the issue should be rejected. 

Comments?

Hesham 

-- 
Thierry ERNST, PhD
http://www.nautilus6.org/~thierry
IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair
--
INRIA Rocquencourt Project-Team IMARA, France.
+33 1 39 63 59 30 (office)