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

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 3 Oct 2006 07:59:31 -0700

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 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Soliman, Hesham" <[email-masked]>
Date: Sat, 7 Oct 2006 06:40:54 -0700

Resending, the first one was too large.  

 In DSMIPv6, I wonder if the requirement "the home agent MUST create two separate binding cache entries, one for each home address"  

=> Are you actually quoting the draft here? I'd like to know that because I think we decided not to use MUSTs for implementation issues, so if a MUST is there it should be removed. 

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

=> They certainly need to be linked regardless of the implementation. Let's understand first what the BC is used for. The BC is like a routing table. So when the HA receives a packet that needs to be tunnelled, it has to look up the BC to find the right entry. Now, how do you suppose an HA receiving an IPv4 packet would look up the BC?? What would it look for to find the entry? If the BC is implemented in the routing table then it looks up the IPv4 dst address. If the BC is separate from the routing table then it needs to find the right entry, either by looking up the IPv4 dst as a HoA or by introducing another level of indirection: i.e. lookup the corresponding IPv6 addr, then look up the BC using that IPv6 HoA. The latter means that all entries are tied to the IPv6 HoA, the former means that each HoA has a separate entry, and of course you can link those entries belonging to one MN. What is the problem?

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.    

=> As I said earlier, this is only a *conceptual data structure*. You can implement it anyway you want.  

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

=> You mean the IPv4 home address and the IPv6 MNPs ? Why ?

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.  

=> Why is it unclear? you'd remove the IPv4 entry in this case. 

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

=> NEMO basic support is exclusively IPv6, so it doesn't need to say the "IPv6 home address". Just like 3775 doesn't say the "IPv6 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 ? 

=> you're quoting the IPv6 only RFC right? it's the IPv6 HoA. It is our responsibility to clarify this in DSMIP, not in NEMO.

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? 

=> As I said earlier it is not something we should mandate at all. We could clarify the consequences of implementation choices of the BC and MNP, but we certainly shouldn't require one way of implementing it. 

Hesham 

Jean-Luc