Subject: RE: [Mip6] Re: [issue66] Setting up forwarding for IPv4 HoA

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 25 Oct 2006 15:13:29 +0200

>-----Original Message-----
>From: Vijay Devarapalli [mailto:[email-masked]]
>Sent: Wednesday, October 25, 2006 1:15 AM
>To: Soliman, Hesham
>Cc: [email-masked]
>Subject: Re: [Mip6] Re: [issue66] Setting up forwarding for IPv4 HoA
>
>Hesham,
>
>I don't believe we can converge on this issue. this
>issue has been open for more than a year and we have
>discussed it too many times. I am tired.
>
[Pascal] OK; let me jump in then. 

I agree with both :) maybe it's a matter of wording.

I do not mind having a conceptual data structure. As Hesham says, we
have that in other drafts. It helps implementers remember the core data
they have to store. The conceptual data can be stored as a single
control block in memory, or as multiple tables in a distributed
database, alone or mixed with other data. That's why it's only
conceptual.

What is NOT conceptual (and that's when I agree with Vijay) is the index
to the data. The protocol must ensure that the index to the conceptual
data is unique. And that unique index in MIP6, NEMO and MIPTRANS is the
IPv6 Home Address. Using an IPv6 address guarantees the global
uniqueness of the index, the scalability of the protocol, etc... And
this is one good reason why MIPTRANS builds on MIP6/NEMO as opposed to
MIP4.

The MIPTRANS conceptual data could be stored in an IPv6 table and an
IPv4 table in a given implementation, but both tables MUST be indexed
with the IPv6 Home Address. In my mind that makes it a single conceptual
binding cache, but that's secondary.

The key is that the IPv4 Home Address in the draft is not a Home Address
stricto sensu, as understood in MIP4, MIP6 and NEMO. It is just an IPv4
address that the Home Agent can bind to that mobile node, just like it
will bind a prefix to a Mobile Router. Note that MRs do not need to bind
an IPv4 Home Address at all: all they need to bind is an IPv4 subnet.

So I'm fine with storing the IPv4 HoA in the conceptual BCE, together
with the prefixes in the BUs as Hesham suggests. I'd wish some text to
make sure that it is very clear that the IPv4 HoA does not inherit the
index characteristics from the MIPx/NEMO RFCs. 

I'm afraid that part of this discussion comes from the name of the
option, IPv4 home address option. Consider this, when the 'p' bit is
set, this is the equivalent of the Mobile Network Prefix Option in NEMO.

Again: MIPTRANS IPv4 home address option IS_SAME_AS RFC3963 Mobile
Network Prefix Option. 

Also, if you go back to RFC 3775, there is a Home Address Option, the
destination option that's used to swap woth the source address in the
packet. And now:

Again: MIPTRANS IPv4 home address option IS_ALIEN_FROM RFC3775 Home
Address Option

Also, the IPv4 address does not have to be from a 'Home'. There might
not be an IPv4 Home. For instance, the HA could be a NAT and give a same
private address to all MNs. You can not do that with MIP4 because the
IPv4 HoA is the index, but MIPTRANS enables this.

Finally, the word "address" is used in the name of the option though for
NEMO it will be a prefix (or a subnet I do not mind the wording).

At the end of the day, I figure that the name of the option is
ill-chosen, and I see that as the source of the miscommunication around
issue 66.

I'd say:

1) About the following text the end of page 18 of version 02
" - If the binding update is accepted for the IPv4 home address, the
     home agent MUST create a binding cache entry for the IPv4 home
     address/prefix. If a single IPv4 home address were requested, it
     MAY be stored in the IPv4-mapped IPv6 address format. The home
     agent MUST include an IPv4 acknowledgement option in the mobility
     header containing the binding acknowledgement.
"

I agree with Vijay that the text should be improved to avoid confusion.
I agree with Hesham that we can keep the conceptual data. I want to make
sure that the IPv4 "HoA" is not confused to be an index to the BCE being
created in that text.

2) About the IPv4 home address option
Can I suggest to rename it "IPv4 addressing option". That removes the
similarity in name with the MIP6 option, and opens to the fact that it
can carry a prefix.

What do you think?

Pascal

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 25 Oct 2006 07:19:31 -0700

I'm glad we have more than two people making comments! 

 > this is one good reason why MIPTRANS builds on MIP6/NEMO as 

=> I completely agree with you. I believe what you're saying is that
it's fine to describe conceptual data in the draft but we need to ensure
that the MN is identified by its IPv6 HoA. This is perfectly fine with
me and essentially guaranteed by the draft since we use MIPv6 and
piggyback additional requests in the BU on the MN's identity, which is
the IPv6 HoA. In other  words, you can't send the BU without the IPv6
HoA.

 > index characteristics from the MIPx/NEMO RFCs. 

=> Fine with me.

 > set, this is the equivalent of the Mobile Network Prefix 

=> Please note that we explicitly state in the draft that we use the
address to represent the address/prefix format, where "prefix" is a
variable length. Similarly, we explicitly state that the term "mobile
node" is used to represent hosts and routers.

 > Again: MIPTRANS IPv4 home address option IS_ALIEN_FROM RFC3775 Home

=> Yes to all of the above.

 > NEMO it will be a prefix (or a subnet I do not mind the wording).

=> Please see above.

 > sure that the IPv4 "HoA" is not confused to be an index to 

=> Feel free to suggest text. The "MUSTs" above should not be there, I
thought I removed them all but I must have missed one.

 > similarity in name with the MIP6 option, and opens to the 

=> That's fine with me.

Hesham

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 26 Oct 2006 02:18:19 +0900

Hi  Hesham,

> I'm glad we have more than two people making comments!

OK, let me jump in, too:-)

I agree with Pascal, too.

There is  another possible problem of using BC for IPv4 HoA.
After MN sends a BU with IPv4 HoA option and registers two bindings  
for both v4 and v6 HoA,
what happened if MN sends de-register BU without IPv4 HoA?
The both bindings should be removed. However, if each HoA is managed  
in separate BC,
it is hard to identify the BC for IPv4 HoA. This is problem when BC  
is indexed by IPv4 HoA.

Anyway, Hesham agree with Pascal.
As Pascal said in the comments,  IPv4 HoA treatment is very similar  
to MNP in the NEMO.
You can simply say that a HA creates a forwarding for each IPv4 HoA  
as RFC3963.
If you really keep the conceptual data,
you should remove all the paragraph saying like

"If the binding update is accepted for both IPv4 and IPv6 home
    addresses, the home agent MUST create two separate binding cache
    entries, one for each home address." (section 4.4)

This text strongly requests creating two binding cache entries to  
implementations.

My suggestion is
"The home agent MUST create a binding cache entry for IPv6 HoA and
  MUST setup  a forwarding for the IPv4 HoA. The forwarding information
  can be stored in anyway  (ex. binding cache entry). "

regards,
ryuji

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Oct 2006 10:58:57 -0700

Pascal Thubert (pthubert) wrote:

> with the IPv6 Home Address. 

YES. this is the point I was trying to make. thank
you.

In my mind that makes it a single conceptual
> index characteristics from the MIPx/NEMO RFCs. 

I can live with this.

> sure that the IPv4 "HoA" is not confused to be an index to the BCE being

agree with the above, but I still think we don't
have to talk about a conceptual data structure at
all for the IPv4 "HoA" similar to how we don't
talk about a conceptual data structure for the
IPv6/IPv4 NEMO prefix.

> similarity in name with the MIP6 option, and opens to the fact that it

agree.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Oct 2006 11:05:18 -0700

RYUJI WAKIKAWA wrote:

> As Pascal said in the comments,  IPv4 HoA treatment is very similar to 
> MNP in the NEMO.
> You can simply say that a HA creates a forwarding for each IPv4 HoA as 
> RFC3963.

building on your text, how about the following?

   The home agent MUST create a binding cache entry for IPv6 HoA and
   MUST setup forwarding for the IPv4 HoA. The forwarding information
   for the IPv4 HoA can be in the form of a routing table entry or a
   separate binding cache entry.  But this information is tied to the
   binding cache entry for the IPv6 HoA and is removed when the
   binding cache entry expires.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Wed, 25 Oct 2006 12:19:59 -0700

I agree with Pascal.

            jak

----- Original Message ----- 
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>; "Soliman, Hesham" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 25, 2006 6:13 AM
Subject: RE: [Mip6] Re: [issue66] Setting up forwarding for IPv4 HoA

I'd say:

What do you think?

Pascal

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 25 Oct 2006 17:31:21 -0700

>    binding cache entry expires.

=> This text is perfectly fine with me, anyone has a problem with this?
If not, then it's in! No more please :)

Hesham

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 26 Oct 2006 12:55:26 +0900

Hi Hesham

Good to have consensus :-)

BTW, shall I open the DT ML archive to public?

regards,
ryuji