Subject: [netlmm] AD review of draft-ietf-netlmm-pmip6-ipv4-support (part 2)

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2009 11:20:33 +0200

My review continues, this time until about page 22. I have also asked 
other reviews, and sent Ralph Droms' review to the list. These need to 
be handled as well.

> 3.1.2.7. Binding Cache Entry Lookup Considerations
>
>
> The Binding Cache entry lookup considerations specified in Section
> 5.4.1.1 of [RFC-5213 <http://tools.ietf.org/html/rfc5213>] requires the Home Network Prefix [RFC-5213 <http://tools.ietf.org/html/rfc5213>] as
> the key parameter for identifying the Binding Cache entry.  When
> using an IPv4 address with a NON_ZERO value, the exact same
> considerations specified in Section 5.4.1.1 of [RFC-5213] <http://tools.ietf.org/html/rfc5213#section-5.4.1.1> MUST be
> applied, with the exception of using an IPv4 home address in place of
> an IPv6 home network prefix.
>
>   

This is not as exact as it should be. For one thing, RFC 5213 talks 
about a set of HNPs, not "the HNP".

Secondly, from the above I do not understand whether you should be 
applying the same rules twice (once for IPv4, then for IPv6) or if you 
should consider the set of HNPs and IPv4 addresses like RFC 5213 
considers a set of HNPs. For instance, RFC 5213 says that if you 
successfully find an entry but some of the HNPs differ then you will 
send back an error. Should you do this if the set of IPv4 addresses and 
IPv6 prefixes do not match what is in the binding entry?

> o The IPv4 home address assigned to the mobile node's attached
>   interface.  The specific details on how the network maintains the
>   association between the address and the attached interface is
>   outside the scope of this document.  This address field also
>   includes the corresponding subnet mask.
>   

I do not understand this. Is this the address to assign to the mobile 
node? If so, this document does define how the address is communicated 
from the LMA to the MAG and eventually to the MN.

> For performing selective de-registration of IPv4 home address but
> still retaining the mobility session with all the IPv6 home
> network prefixes, the Proxy Binding Update message with the
> lifetime value of 0 MUST NOT include any IPv6 Home Network Prefix
> options(s)
The draft should upfront explain what the model for Binding Updates and 
binding entries is wrt IPv4 and IPv6. See my first comment above. 
Presumably there is exactly one binding entry, right? Can that entry be 
updated partially or always at one go? What are the rules for changing 
HNPs or IPv4 addresses in a registration?

>  IPv4 Default-Router Address
>
>  A four-byte field containing the mobile node's default router address.
>   
Are we communicating only the IP address? What happens when, from the 
point of view of the mobile host, the IP setup stays the same but the 
hardware address of the default router changes? It would seem that this 
fails with IPv4 DNA, for instance, because it would send a unicast ARP 
request to the previously used default router's hardware address.

Jari

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 5 Feb 2009 00:38:27 +0900

Hi Jari,

Thanks for AD review.

Regarding the binding cache treatment, the base DSMIPv6 advises
to create separate bindings for IPv4 and IPv6 home addresses.

"After receiving the binding update, the home agent creates
    two binding cache entries, one for the mobile node's IPv4 home
    address, and another for the mobile node's IPv6 home address."

"After accepting the binding update, the home agent MUST create a new
    binding cache entry for the mobile node's IPv6 home address.  If an
    IPv4 home address option were included, the home agent MUST create
    another entry for that address."

My understanding is to manage the binding cache separetely for IPv4
HoA and IPv6 MNP.

 > request to the previously used default router's hardware address.

Good point.
We probably let MAG send gratuitous ARP reply to update
the ARP entry at MN.
I might miss something though, I don't know the detail of IPv4 DNA.

thanks,
ryuji

On 2009/02/04, at 18:20, Jari Arkko wrote:

> My review continues, this time until about page 22. I have also  
> asked other reviews, and sent Ralph Droms' review to the list. These  
> need to be handled as well.
>
>> 5.4.1.1 of [RFC-5213 <http://tools.ietf.org/html/rfc5213>] requires  
>> the Home Network Prefix [RFC-5213 <http://tools.ietf.org/html/ 
>> rfc5213>] as
>> considerations specified in Section 5.4.1.1 of [RFC-5213] <http://tools.ietf.org/html/rfc5213#section-5.4.1.1 
>> > MUST be
> applying the same rules twice (once for IPv4, then for IPv6) or if  
> you should consider the set of HNPs and IPv4 addresses like RFC 5213  
> send back an error. Should you do this if the set of IPv4 addresses  
> and IPv6 prefixes do not match what is in the binding entry?
>
> I do not understand this. Is this the address to assign to the  
> mobile node? If so, this document does define how the address is  
> communicated from the LMA to the MAG and eventually to the MN.
>
> The draft should upfront explain what the model for Binding Updates  
> and binding entries is wrt IPv4 and IPv6. See my first comment  
> above. Presumably there is exactly one binding entry, right? Can  
> that entry be updated partially or always at one go? What are the  
> rules for changing HNPs or IPv4 addresses in a registration?
>
> Are we communicating only the IP address? What happens when, from  
> the point of view of the mobile host, the IP setup stays the same  
> but the hardware address of the default router changes? It would  
> seem that this fails with IPv4 DNA, for instance, because it would  
> send a unicast ARP request to the previously used default router's  
> hardware address.
>
> Jari
>
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 4 Feb 2009 22:23:41 -0800 (PST)

Hi Jari,

Please see inline.

On Wed, 4 Feb 2009, Jari Arkko wrote:

> My review continues, this time until about page 22. I have also asked other 
> reviews, and sent Ralph Droms' review to the list. These need to be handled 
> as well.

Yes. We have to follow up on Ralph's review and close that
thread.

>>  5.4.1.1 of [RFC-5213 <http://tools.ietf.org/html/rfc5213>] requires the
>>  Home Network Prefix [RFC-5213 <http://tools.ietf.org/html/rfc5213>] as
>>  considerations specified in Section 5.4.1.1 of [RFC-5213]
>>  <http://tools.ietf.org/html/rfc5213#section-5.4.1.1> MUST be
> This is not as exact as it should be. For one thing, RFC 5213 talks about a 
> set of HNPs, not "the HNP".
>

This is the remnant from the prev versions, where we supported multiple
IPv4 HoA's. We thought we smartly mapped it to the IPv6 section of the
lookup logic :), now with the change to single IPv4 HoA support, this
needs to be fixed. But, it is simplied now. Will fix it, thanks.

> Secondly, from the above I do not understand whether you should be applying 
> the same rules twice (once for IPv4, then for IPv6) or if you should consider 
> the set of HNPs and IPv4 addresses like RFC 5213 considers a set of HNPs. For 
> instance, RFC 5213 says that if you successfully find an entry but some of 
> the HNPs differ then you will send back an error. Should you do this if the 
> set of IPv4 addresses and IPv6 prefixes do not match what is in the binding 
> entry?
>

No. We are applying the rules only once. Any of the keys can be used
for the BCE lookup. The lookup rules in 3.1.2.7 are when using IPv4
HoA. Will make it bit more explicit.

> I do not understand this. Is this the address to assign to the mobile node? 
> If so, this document does define how the address is communicated from the LMA 
> to the MAG and eventually to the MN.
>

As in 5213, we allow the policy profile to have the IPv4 HoA,
statically defined, just as how we allowed it in 5213. This is
optional. When such IPv4 address is specified in a given MN's
profile, the MAG can request the LMA for the same to be allocated.
Now, w.r.t the deliverly, either when the DHCP server is co-located
on the LMA or on the MAG, that protocol plane needs to ensure the
same address is assigned. So, having this address in policy profile,
is not changing the fundamental requirement of the DHCP or address
configuration protcols and the PMIP elements to have some level
of interaction to ensure the assigned address in both the planes
is same.

> binding entries is wrt IPv4 and IPv6. See my first comment above. Presumably 
> there is exactly one binding entry, right? Can that entry be updated 
> partially or always at one go? What are the rules for changing HNPs or IPv4 
> addresses in a registration?
>

Ok. Initial thought was to keep it just way, through out and not
have this selective addition or deletion. However, to support the
3GPP's requirement of deferred address support, we had to add this.
Will clarify this in the initial sections.

> Are we communicating only the IP address? What happens when, from the point 
> of view of the mobile host, the IP setup stays the same but the hardware 
> address of the default router changes? It would seem that this fails with 
> IPv4 DNA, for instance, because it would send a unicast ARP request to the 
> previously used default router's hardware address.
>

5213 already required the link-layer address of the MAG to be
a fixed address on all links, to avoid all the issues as we
discussed during the IESG reviews. So, the IPv4 doc is bound
to that requirement and hence hardware address of the DR as seen by
the MN should remain fixed.

Regards
Sri

---

From: Jari Arkko <[email-masked]>
Date: Thu, 05 Feb 2009 10:17:29 +0200

Sri,

> IPv4 HoA's.

I guessed as much.

> We thought we smartly mapped it to the IPv6 section of the

Good.

> HoA. Will make it bit more explicit.

Ok. So if you look up based on HNP1 from the BU that has (HNP1, HNP2, 
V4ADDR1) and the BCE has (HNP1, HNP2, V4ADDR2) there's going to be an 
error back to the sender? This seems right.

>> node? If so, this document does define how the address is 
> statically defined, just as how we allowed it in 5213.

Fine.

> This is

Yes.

> of interaction to ensure the assigned address in both the planes

Sure.

But I still do not understand what your text in the document attempted 
to say. Do you mean that while PMIP ensures that the address is in sync 
between the profile, LMA, and MAG, the actual address assignment to the 
mobile node happens via DHCP?

>> and binding entries is wrt IPv4 and IPv6. See my first comment above. 
>> Presumably there is exactly one binding entry, right? Can that entry 
>> be updated partially or always at one go? What are the rules for 
>> changing HNPs or IPv4 addresses in a registration?
>>
>

OK. But please do not break the old model from RFC 5213 where the HNP 
set had to stay unchanged. I do not think we should change the 
principles based on which address family we are dealing with.

>> hardware address of the default router changes? It would seem that 
>> this fails with IPv4 DNA, for instance, because it would send a 
>> unicast ARP request to the previously used default router's hardware 
>> address.
>>
>

Ok. Can you add explicit note about this to the v4 document?

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 5 Feb 2009 08:39:30 -0800 (PST)

Hi Jari,

On Thu, 5 Feb 2009, Jari Arkko wrote:

> V4ADDR1) and the BCE has (HNP1, HNP2, V4ADDR2) there's going to be an error 
> back to the sender? This seems right.
>

Yes. We try to match all the entries in the binding, both IPv6 and
IPv4 entries. Will check through all combinations, to see we are not
missing any case here.

>
> But I still do not understand what your text in the document attempted to 
> say. Do you mean that while PMIP ensures that the address is in sync between 
> the profile, LMA, and MAG, the actual address assignment to the mobile node 
> happens via DHCP?
>
>

This is w.r.t multi-homing support. If the terminal is a multi-homed
terminal, the static address specified in the policy profile needs
to be associated with a given interface of a mobile node and especially
when that relation changes after a inter-interface handoff, but the
policy profile still needs to track that association. We tried to say
how that is done is out of scope just as in 5213.

   "The IPv4 home address assigned to the mobile node's attached
    interface.  The specific details on how the network maintains the
    association between the address and the attached interface is
    outside the scope of this document.  This address field also
    includes the corresponding subnet mask."

> OK. But please do not break the old model from RFC 5213 where the HNP set had 
> to stay unchanged. I do not think we should change the principles based on 
> which address family we are dealing with.
>

Within the address family, we are keeping the address set a fixed set
as in 5213. We just allowed the addition/deletion of a given address
family as a whole during re-registrations. So, the base rule that we
followed earlier is still intact.

> Ok. Can you add explicit note about this to the v4 document?

Sure. We will add this.

Thanks
Sri