Subject: Re: [MEXT] draft-premec-mext-extended-home-link-01

From: Christian Kaas-Petersen <[email-masked]>
Date: Fri, 3 Apr 2009 08:36:44 +0000 (GMT)

Proposal: Introduce a Tunnel (T) bit in the BU to signal an 
IPv4 tunnel to be created on the home link.

Introducing modified semantics on mobility options appearing in 
BUs sent the home link (as done in draft-premec) is not the way ahead.  
The reason is simplificy of design: one option has one purpose.

The C-bit in the BU has been suggested as a way to signal the
BU is sent on the home link for the purpose of configuration
(done in draft-devarapalli).  What exactly to be configured
depends on the mobility options present.

This mail suggest a T-bit in the BU as a way to signal a tunnel
to be established.  Currently, only one tunnel is foreseen, namely
the IPv4-in-IPv6 tunnel for IPv4 traffic over an IPv6-only home
link.  The tunnel is indicated with the IPv4 Home Address mobility
option.  The tunnel could be established as the entry
v4HoA -> v6HoA in the binding cache.  The T-bit may be set, only
when also the C-bit is set.  Having T-bit set and C-bit clear
is an error.  Having T-bit set and IPv4 Home Address mobility
option missing is probly an error.  There should be no need 
to include IPv4 Care-of Address mobility option, as its content
will be the same as the IPv4 Home Address mobility option.

Not clear what the BU's lifetime should be.  With the C-bit set,
configurations can be done, for example to obtain an IPv4 home
address or a NEMO mobile network prefix.  The values returned
may be dynamically assigned by the home agent.  The home agent
would probably be interested in knowing for how long time the
assigned values will be used.  A practical solution for this
is to say the assignment is valid as long as the mobile node
remains on the home link and as long as the IKE session
is alive between the mobile node and the home agent. 

Christian

--- Den tors 2/4/09 skrev Behcet Sarikaya <[email-masked]>:

Fra: Behcet Sarikaya <[email-masked]>
Emne: Re: SV: [MEXT] draft-premec-mext-extended-home-link-01
Til: "Domagoj Premec" <[email-masked]>, "Christian Kaas-Petersen" <[email-masked]>, [email-masked]
Dato: torsdag 2. april 2009 16.55

Hi Domagoj,
  You need to indicate to HA that this is a non-deregistration BU sent from the home link. So the correct way is to define a flag at the BU message like the C flag in http://tools.ietf.org/id/draft-devarapalli-mext-mipv6-home-link-01.txt
  Of course HA may also set the C flag in its reply of BA message. I think this was what Vijay was commenting on last week at the mext meeting.
  Yes, IPv4 HoA option has some bits available but these would apply to this option not to the BU message, I think it would be wrong to define this bit there.
  Regards,
 
Behcet

From: Domagoj Premec <[email-masked]>
To: Behcet Sarikaya <[email-masked]>; Christian Kaas-Petersen <[email-masked]>; [email-masked]
Cc: Charles E. Perkins <[email-masked]>
Sent: Thursday, April 2, 2009 4:40:13 AM
Subject: RE: SV: [MEXT] draft-premec-mext-extended-home-link-01

Behcet,

In draft-devarapalli-mext-mipv6-home-link-01 the C flag is being defined as
part of the BU and Back messages. Given that draft-premec-extended-home-link
is about registering for the v4 service from the IPv6-only home link, there
is always the IPv4 HoA option included and in this case it may be more
appropriate to define the new flag as part of the IPv4 HoA option. This
would save the flag space in the BU/Back without having disadvantages in the
extended home link scenario.

domagoj

________________________________

    From: ext Behcet Sarikaya [mailto:[email-masked]] 
    Sent: 01. travanj 2009 16:39
    To: Christian Kaas-Petersen; [email-masked]
    Cc: Charles E. Perkins; Domagoj Premec
    Subject: Re: SV: [MEXT] draft-premec-mext-extended-home-link-01

    Hi Christian,
      I am OK redefining the C Flag for this purpose. If other uses come
up they should make their own case, I think.
    
    Regards,
    
    Behcet

    ________________________________

    From: Christian Kaas-Petersen <[email-masked]>
    To: [email-masked]; Behcet Sarikaya <[email-masked]>
    Cc: Charles E. Perkins <[email-masked]>; Domagoj Premec
<[email-masked]>
    Sent: Wednesday, April 1, 2009 2:31:59 AM
    Subject: SV: [MEXT] (no subject)

    The C flag, as defined in draft-devarapalli, means the home agent
    shall do various processing, but shall not create an entry in the
    binding cache.  However, draft-premec requires an entry in the
    binding cache to be created in order to tunnel IPv4 packets.
    So, either the semantics of the C flag shall be extended or
    another flag shall be defined.  What is your suggestion?
    
    Christian

    --- Den tirs 31/3/09 skrev Behcet Sarikaya
<[email-masked]>:
    
    > Fra: Behcet Sarikaya <[email-masked]>
    > Emne: [MEXT] (no subject)
    > Til: [email-masked]
    > Cc: "Charles E. Perkins" <[email-masked]>, "Domagoj Premec"
<[email-masked]>
    > Dato: tirsdag 31. marts 2009 22.19
    > Hello all,
    >  Regarding
    > draft-premec-mext-extended-home-link-01.txt, I noticed that
    > this draft is about what I asked Charlie last week during
    > his presentation, i.e. sending BU at the home link for
    > something other than deregistration. As the draft says in
    > Sec. 4.1:
    > When the MN returns home to an IPv6-only home network,
    > the MN sends ... BU
    >  I agree with Vijay that a flag must be defined
    > and set for this purpose because normally this is not
    > allowed and HA must probably reject such a BU. A flag
    > to this end has already been suggested in
    > draft-devarapalli-mext-mipv6-home-link-01 as C flag.
    >  
    > Regards,
    >  
    > Behcet
    > 
    > 
    >      
    > -----Inline-vedhæftet fil følger-----
    > 
    > _______________________________________________
    > MEXT mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/mext
    > 

      Trænger du til at se det store billede? Kelkoo giver dig gode tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 3 Apr 2009 08:56:33 -0700 (PDT)

A bit (C-bit, whatever bit) is needed to indicate a non-deregistration BU sent at the home link. Maybe the right place is 3775bis. I was trying to indicate this last week in mext session, but Marcelo cut me off saying that the issues with 3775bis have been closed.

Once this bit is defined, draft-premec can have a normative statement to require this bit be set and then introduce IPv4 HoA issue.

This is my understanding.

Regards,

Behcet

________________________________
From: Christian Kaas-Petersen <[email-masked]>
To: Domagoj Premec <[email-masked]>; [email-masked]; Behcet Sarikaya <[email-masked]>
Sent: Friday, April 3, 2009 3:36:44 AM
Subject: Re: SV: [MEXT] draft-premec-mext-extended-home-link-01

to be established..  Currently, only one tunnel is foreseen, namely

Christian

Fra: Behcet Sarikaya <[email-masked]>
Emne: Re: SV: [MEXT] draft-premec-mext-extended-home-link-01
Til: "Domagoj Premec" <[email-masked]>, "Christian Kaas-Petersen" <[email-masked]>, [email-masked]
Dato: torsdag 2.. april 2009 16.55

Hi Domagoj,
 
Behcet

Behcet,

domagoj

    Hi Christian,
    
    Regards,
    
    Behcet

    
    Christian

    > https://www.ietf..org/mailman/listinfo/mext
    >

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 7 Apr 2009 15:55:03 +0200

Christian, Behcet,

I'm not clear on benefits of using the C bit, is there really a need to require usage of two separate bits in the BU in the context of extended home link support? I'd like the draft to be as self-contained as it gets, this should help speed up the progress of the draft and avoiding references to other drafts should help in that regard. It seems to me that using only the T bit should suffice, are there any concerns that make the use of C bit as defined in draft-devarapalli-mext-mipv6-home-link necessary?

Domagoj

> -----Original Message-----
> From: ext Christian Kaas-Petersen [mailto:[email-masked]] 
> Sent: 03. travanj 2009 10:37
> To: Domagoj Premec; [email-masked]; Behcet Sarikaya
> Introducing modified semantics on mobility options appearing 
> in BUs sent the home link (as done in draft-premec) is not 
> the way ahead.  
> This mail suggest a T-bit in the BU as a way to signal a 
> tunnel to be established.  Currently, only one tunnel is 
> foreseen, namely the IPv4-in-IPv6 tunnel for IPv4 traffic 
> over an IPv6-only home link.  The tunnel is indicated with 
> the IPv4 Home Address mobility option.  The tunnel could be 
> established as the entry v4HoA -> v6HoA in the binding cache. 
>  The T-bit may be set, only when also the C-bit is set.  
> Having T-bit set and C-bit clear is an error.  Having T-bit 
> set and IPv4 Home Address mobility option missing is probly 
> an error.  There should be no need to include IPv4 Care-of 
> Address mobility option, as its content will be the same as 
> the IPv4 Home Address mobility option.
> 
> Not clear what the BU's lifetime should be.  With the C-bit 
> set, configurations can be done, for example to obtain an 
> IPv4 home address or a NEMO mobile network prefix.  The 
> values returned may be dynamically assigned by the home 
> agent.  The home agent would probably be interested in 
> knowing for how long time the assigned values will be used.  
> A practical solution for this is to say the assignment is 
> valid as long as the mobile node remains on the home link and 
> as long as the IKE session is alive between the mobile node 
> and the home agent. 
> 
> Christian
> 
> 
> 
> 
> 
> Til: "Domagoj Premec" <[email-masked]>, 
> "Christian Kaas-Petersen" <[email-masked]>, [email-masked]
>   You need to indicate to HA that this is a 
> non-deregistration BU sent from the home link. So the correct 
> way is to define a flag at the BU message like the C flag in 
> http://tools.ietf.org/id/draft-devarapalli-mext-mipv6-home-link-01.txt
>   Of course HA may also set the C flag in its reply of BA 
> message. I think this was what Vijay was commenting on last 
> week at the mext meeting.
>   Yes, IPv4 HoA option has some bits available but these 
> would apply to this option not to the BU message, I think it 
> would be wrong to define this bit there.
>   Regards,
>  
> Behcet
> 
> 
> 
> 
> 
> To: Behcet Sarikaya <[email-masked]>; Christian 
> Kaas-Petersen <[email-masked]>; [email-masked]
> In draft-devarapalli-mext-mipv6-home-link-01 the C flag is 
> being defined as part of the BU and Back messages. Given that 
> draft-premec-extended-home-link is about registering for the 
> v4 service from the IPv6-only home link, there is always the 
> IPv4 HoA option included and in this case it may be more 
> appropriate to define the new flag as part of the IPv4 HoA 
> option. This would save the flag space in the BU/Back without 
> having disadvantages in the extended home link scenario.
> 
> domagoj
> 
> 
> 
>       I am OK redefining the C Flag for this purpose. If 
> other uses come up they should make their own case, I think.
>     
>     Regards,
>     
>     Behcet
>     
> 
>     Cc: Charles E. Perkins <[email-masked]>; Domagoj 
> Premec <[email-masked]>
>       Trænger du til at se det store billede? Kelkoo giver 
> dig gode tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 7 Apr 2009 07:42:55 -0700 (PDT)

Domagoj,
  I am not sure if you can avoid the C bit because without it HA will reject the BU before it gets to the T bit.
  Because of that I am not sure if T bit is of any use at all.
  Maybe you can negotiate with Charlie/Vijay?

Regards,

Behcet

________________________________
From: "Premec, Domagoj" <[email-masked]>
To: ext Christian Kaas-Petersen <[email-masked]>; [email-masked]; Behcet Sarikaya <[email-masked]>
Sent: Tuesday, April 7, 2009 8:55:03 AM
Subject: RE: SV: [MEXT] draft-premec-mext-extended-home-link-01

Christian, Behcet,

Domagoj