Subject: [MEXT] IPv4 home address option in DSMIP

From: Shi Xiaoyan <[email-masked]>
Date: Sat, 17 Jan 2009 16:17:08 +0800

Hi Hesham,
 
Section 5.4.2
 
   When sending a binding update from a visited network that supports
   IPv6, the mobile node MUST follow the rules specified in [RFC3775].
   In addition, if the mobile node has an IPv4 home address or needs
   one, it MUST include the IPv4 home address option in the mobility
   header.  
 
Does the IPv4 home address option must be include in Binding Update even if
BU is send for extend binding lifetime?
I think it is redundant since only IPv6 HoA is the key for BCE lookup. In
maillist, I find some disscussion mails about this quesion, but I can't find
the reason why all BU must include IPv4 home address option. 

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

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 18 Jan 2009 01:40:33 +1100

> BU is send for extend binding lifetime?

=> Yes. 

> the reason why all BU must include IPv4 home address option.

=> Two reasons:
1. This is how a BU works, all options need to be included in order for a
binding to be refreshed
2. The only way the MN can delete the IPv4 binding is to not include it in
the BU. 

Hesham

---

From: Shi Xiaoyan <[email-masked]>
Date: Mon, 19 Jan 2009 09:48:38 +0800

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Saturday, January 17, 2009 10:41 PM
> To: Shi Xiaoyan
> Cc: [email-masked]
> Subject: Re: IPv4 home address option in DSMIP
> 
> 

> 
> > I think it is redundant since only IPv6 HoA is the key for 
> BCE lookup. 
> > In maillist, I find some disscussion mails about this 
> quesion, but I 
> > can't find the reason why all BU must include IPv4 home 
> address option.
> 
> => Two reasons:
> 1. This is how a BU works, all options need to be included in 
> order for a binding to be refreshed 2. The only way the MN 
> can delete the IPv4 binding is to not include it in the BU. 

1. BU without IPv4 home address option works well for extending lifetime. I
can't understand what you said "how a BU works". Is there any Specification
to require that BU for exending lifetime  must be consistent with BU for
first register? Is there any special effect? In fact, with more and more
extension for BU in future, the requirement that BU for exending lifetime
must be consistent with BU for first register will cause unnecessary load.

2. We can find many other ways to delete the IPv4 binding if it is consensus
that re-registration BU does not have to include the IPv4 HAO. It could not
be a resason for re-registration BU must including IPv4 HAO.

Regards,
Xiaoyan

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 19 Jan 2009 23:03:40 +1100

> must be consistent with BU for first register will cause unnecessary load.

=> Yes I know that will use more bandwidth but I don't understand what
you're objecting to. Implementations copy the contents of the new BU into
the BC to replace the old entry, as specified in 3775. So a new BU
overwrites the old one unless you desgin a new option per extension that
tells the receiver to only refresh.

> be a resason for re-registration BU must including IPv4 HAO.

=> Well, that's the reason now, if you have better ideas, other than
designing a new option per extension please send them to the list. This is
already a bit late given that I'm making the last update for IESG comments.

Hesham

---

From: Shi Xiaoyan <[email-masked]>
Date: Tue, 20 Jan 2009 18:05:56 +0800

> Sent: Monday, January 19, 2009 8:04 PM
> To: Shi Xiaoyan
> Cc: [email-masked]

> > 1. BU without IPv4 home address option works well for extending 
> > lifetime. I can't understand what you said "how a BU 
> works". Is there 
> > any Specification to require that BU for exending lifetime  must be 
> > consistent with BU for first register? Is there any special 
> effect? In 
> > fact, with more and more extension for BU in future, the 
> requirement 
> > that BU for exending lifetime must be consistent with BU 
> for first register will cause unnecessary load.
> 
> => Yes I know that will use more bandwidth but I don't 
> understand what you're objecting to. Implementations copy the 
> contents of the new BU into the BC to replace the old entry, 
> as specified in 3775. So a new BU overwrites the old one 
> unless you desgin a new option per extension that tells the 
> receiver to only refresh.
> 

In my opinion, re-registration BU should not include the IPv4 HAO. Because
re-registration BU with IPv4 HAO
1. Need more bandwidth.
2. Cause extra load on HA. Because HA must verify if  the address in IPv4
HAO match that in BCE in order to avoid MN use a unauthorized IPv4 address. 

In fact, since "the home agent MUST be able to find the IPv4 home address of
a mobile node when given the IPv6 home address", section 5.5, why IPv4 HAO
must be include in re-registration BU? I can't find any benefit. 

I didn't find the description in 3775 for "a new BU overwrites the old one".
It should be implementation issue.
It also could be done as that attributes in BCE also include in
re-registration BU should be overwriten and other attribute not included in
re-registration BU should remain valid.  

De-registration for IPv4 HoA can be done by adding a bit in IPv4 HAO option
for indicating de-registration, or any other ways. It is all ok. 
I just think it is unnecessary that re-registration BU include the IPv4 HAO.
:-)

> > 
> > 2. We can find many other ways to delete the IPv4 binding if it is 
> > consensus that re-registration BU does not have to include the IPv4 
> > HAO. It could not be a resason for re-registration BU must 
> including IPv4 HAO.
> 
> => Well, that's the reason now, if you have better ideas, 
> other than designing a new option per extension please send 
> them to the list. This is already a bit late given that I'm 
> making the last update for IESG comments.
> 
> Hesham
> 
> > 
> >> 
> >> Hesham
> >> 
> >>>  
> >>> 
> >>> Regards,
> >>> Xiaoyan
> >> 
> > 
> > Regards,
> > Xiaoyan
> > 
> 
>

---

From: Shi Xiaoyan <[email-masked]>
Date: Fri, 23 Jan 2009 11:35:56 +0800

HA doesn't replace the BCE such as remove the old BCE and creat a new one
when recieved BU.
HA just update the option in BCE also included in BU and others option in
BCE remain valid. 

Such as draft-ietf-monami6-multiplecoa-11,  When multiple Binding Identifier
mobility options are present in the Binding Update, it is treated as bulk
registration. But not all BCE should be removed. Only when 'O' flag is set,
HA remove all old BCE. 

Regards,
Xiaoyan

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Shi Xiaoyan
> Sent: Tuesday, January 20, 2009 6:06 PM
> To: 'Hesham Soliman'
> Cc: [email-masked]
> Subject: Re: [MEXT] IPv4 home address option in DSMIP
> 
> 
> 
> understand what 
> > you're objecting to. Implementations copy the contents of 
> the new BU 
> > into the BC to replace the old entry, as specified in 3775. 
> So a new 
> > BU overwrites the old one unless you desgin a new option 
> per extension 
> > that tells the receiver to only refresh.
> > 
> 
> In my opinion, re-registration BU should not include the IPv4 
> HAO. Because re-registration BU with IPv4 HAO 1. Need more bandwidth.
> 2. Cause extra load on HA. Because HA must verify if  the 
> address in IPv4 HAO match that in BCE in order to avoid MN 
> use a unauthorized IPv4 address. 
> 
> In fact, since "the home agent MUST be able to find the IPv4 
> home address of a mobile node when given the IPv6 home 
> address", section 5.5, why IPv4 HAO must be include in 
> re-registration BU? I can't find any benefit. 
> 
> It also could be done as that attributes in BCE also include 
> in re-registration BU should be overwriten and other 
> attribute not included in re-registration BU should remain valid.  
> 
> De-registration for IPv4 HoA can be done by adding a bit in 
> IPv4 HAO option for indicating de-registration, or any other 
> ways. It is all ok. 
> other than 
> > designing a new option per extension please send them to the list. 
> > This is already a bit late given that I'm making the last 
> update for 
> > IESG comments.
> > 
> > Hesham
> > 
> > > 
> > >> 
> > >> Hesham
> > >> 
> > >>>  
> > >>> 
> > >>> Regards,
> > >>> Xiaoyan
> > >> 
> > > 
> > > Regards,
> > > Xiaoyan
> > > 
> > 
> > 
>

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 23 Jan 2009 15:17:43 +1100

> registration. But not all BCE should be removed. Only when 'O' flag is set,

=> We've discussed this specific point for the MCoA draft and for flow
binding. Ryuji explicitly stated that they did modify the semantics of the
BU for that draft. Please review those exchanges to see the details.

I don't see the need for doing what you suggested below because it adds
ambiguity and the benfits are minimal. Given this late stage I'm not in
favour of making further optimisations. No one else seems to express
opinions on this so my preference is to leave it as it is.

Hesham

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 23 Jan 2009 08:27:34 -0800

Gerardo

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hesham
> Soliman
> Sent: Thursday, January 22, 2009 8:18 PM
> To: Shi Xiaoyan
> Cc: [email-masked]
> On 23/01/09 2:35 PM, "Shi Xiaoyan" <[email-masked]> wrote:
> 
> > Hi Hesham,
> >

---

From: Yungui Wang <[email-masked]>
Date: Sat, 24 Jan 2009 09:01:46 +0800

Maybe rfc3775bisxxx need state the explicit action of HA 'how to do when a mobility option is (not) carried within the lifetime extension re-registration (BU)'. Then, new MO in the subsequent draft could make consistent. 

B.R.
Yungui

  ----- Original Message ----- 
  From: Giaretta, Gerardo 
  To: Hesham Soliman ; Shi Xiaoyan 
  Cc: [email-masked] 
  Sent: Saturday, January 24, 2009 12:27 AM
  Subject: Re: [MEXT] IPv4 home address option in DSMIP

  I agree with Hesham on this.

  Gerardo