Subject: [MEXT] issue for rfc3775bis

From: "Alper Yegin" <[email-masked]>
Date: Wed, 19 Nov 2008 22:43:51 +0200

Following the discussions we had on the reflector, I think the RFC 3775bis
needs improvement for use of Alt-CoA option and BA destination address.

The spec clearly states that the BA is sent back to the source IP address of
the BU (not to CoA, which may be different when Alt CoA is used):

   If the Source Address field of the IPv6 header that carried the

   Binding Update does not contain a unicast address, the Binding

   Acknowledgement MUST NOT be sent and the Binding Update packet MUST

   be silently discarded.  Otherwise, the acknowledgement MUST be sent

   to the Source Address.

I'm not sure if this deserves additional clarification/specification text.
Vijay believes there is an issue in the absence of further text that talks
about how HA stores the source IP address of the last received BU. I agree
that is needed for revocation spec and it can be specified there as one
option.

Any thoughts? Is there anything we need to do in RFC 3775bis? 

Alper

 

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Nov 2008 11:34:52 -0800

Hi Alper,

It is not really a bug in RFC 3775. RFC 3775 never considered separation 
of control and data plane for the mobile node and the home agent. You 
are asking for the HA to store both the source address of the BU and the 
address in the AltCoA option in the binding cache entry if the two 
happen to be different. And further you want all signaling messages to 
be sent to the source address in the BU and the data packets sent to the 
address in the AltCoA option. IMO, this would be a new feature in RFC 
3775, not a bug fix. :)

Vijay

Alper Yegin wrote:

> Following the discussions we had on the reflector, I think the RFC 
> 3775bis needs improvement for use of Alt-CoA option and BA destination 
> address.
> 
>  
> 
>  
> 
> The spec clearly states that the BA is sent back to the source IP 
> address of the BU (not to CoA, which may be different when Alt CoA is used):
> 
>  
> 
> I’m not sure if this deserves additional clarification/specification 
> text. Vijay believes there is an issue in the absence of further text 
> that talks about how HA stores the source IP address of the last 
> received BU. I agree that is needed for revocation spec and it can be 
> specified there as one option.
> 
>  
>

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 20 Nov 2008 21:58:28 +0200

Vijay,

> of control and data plane for the mobile node and the home agent. 

You are saying that because you don't see a section titled "Separation of
Control and Data Plane" in the RFC :) 
If being able to send MIP signaling between IP1 and HA_IP, and getting the
IP packets tunneled between IP2 and HA_IP (as this scenario is enabled by
Alt-CoA today!) is not called "separation of control and data plane" in your
mind, I wonder what is? 

> You

Really? It's all in the RFC 3775:

I hope some other folks join the discussion, as this is my second pass on
the same arguments with Vijay :)

Alper

> > I'm not sure if this deserves additional clarification/specification

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Nov 2008 12:04:43 -0800

Alper,

Well, the fact is that you need significant changes to RFC 3775 to 
explicitly support separation of control and data plane using the AltCoA 
option. You can't claim it is a "bug fix" and modify some text. :)

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 20 Nov 2008 22:22:40 +0200

> option. You can't claim it is a "bug fix" and modify some text. :)

No.... you need NO change on the base spec. As I quoted earlier, spec is
very clear. I don't know what you think is missing in RFC 3775.

Now, the question is: where does the HA pull the source address of the last
received BU if it is generating a BRI? We can address that in the Binding
Revocation draft by adding that piece of information to the binding cache
entry. 

[IMHO, we can also add that to the base spec, but I see people are
uncomfortable with doing that]

Alper

> >>> address of the BU (not to CoA, which may be different when Alt CoA
> is
> >> used):
> >>>
> >>>

---

From: Brian Haley <[email-masked]>
Date: Fri, 21 Nov 2008 14:59:08 -0500

>> address in the AltCoA option. IMO, this would be a new feature in RFC

Most implementations probably *are* storing the original source address, 
since sending the BAck sometimes requires waiting for DAD to complete, 
so the info is there.

> the same arguments with Vijay :)

I guess you're talking about me? :)

> uncomfortable with doing that]

So the issue is "where do we send future packets for this MN ?".  I 
think the preferred way would be to the Alt-CoA since that's the remote 
tunnel endpoint, and we know packets can get there.  But in reality we 
should be able to send it to either.  Do we need to clarify that in the 
base spec?

-Brian