Subject: [Hipsec] RFC5206 and LOCATOR parameter

From: Miika Komu <[email-masked]>
Date: Wed, 24 Feb 2010 14:29:37 +0200

Hi Tom,

there was some discussion about the nat-mm draft which brought another 
somewhat related thought into my mind. Tom, Have you thought about 
fixing the format or position the locators in RFC5206?

The fact that we now have three different types of locators makes things 
unnecessarily complicated. IMHO we could just settle to type 2 locators 
which are the superset of the other locators.

The position of the LOCATORs varies at the Responder. RFC5206 place it 
R1 whereas the NAT traversal extension places it in R2. While both of 
the positions can be argumented, they introduce complexity for the 
implementation. I would suggest simplifying this and just place the 
LOCATOR parameter always to R2. This would exclude the "load balancing" 
feature achieved by the LOCATOR parameter in the R1 packet, but this is 
nothing that couldn't already be achieved with DNS-based schemes.

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Wed, 24 Feb 2010 14:23:40 -0800

> The position of the LOCATORs varies at the Responder. RFC5206
> place it R1 whereas the NAT traversal extension places it in R2.
> While both of

I'd agree with this... one of the complexities that I dislike about placing LOCATORs in the R1 is that every time your locator set changes (if including all addresses) or every time your preferred locator changes, you need to invalidate your entire R1 cache and recompute it. This would occur at a time when you are already (possibly) busy generating and processing UPDATEs for the locator change.

-Jeff

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 24 Feb 2010 21:07:50 -0800

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]]
> Sent: Wednesday, February 24, 2010 4:30 AM
> To: Henderson, Thomas R
> Cc: hip WG
> Subject: RFC5206 and LOCATOR parameter
>
> Hi Tom,
>

No, not yet.  I thought that RFC5206bis had to at least account for the R2 locators, but wasn't thinking about reducing the other use cases.

> which are the superset of the other locators.

Are you asking about having only one type code and parameter format, or one parameter format, with different type codes possible (the types can govern whether certain fields are valid)?

> place it

I am not sure yet; we should probably study some use cases to decide.  Many hosts can't control their DNS records (if present) as you suggest.

- Tom

---

From: Miika Komu <[email-masked]>
Date: Thu, 25 Feb 2010 09:05:49 +0200

On 25/02/10 07:07, Henderson, Thomas R wrote:

Hi,

>> The fact that we now have three different types of locators makes
>> things unnecessarily complicated. IMHO we could just settle to
>> type 2 locators which are the superset of the other locators.
>
> Are you asking about having only one type code and parameter format,
> or one parameter format, with different type codes possible (the
> types can govern whether certain fields are valid)?

I was asking to invalidate type 0 and type 1 locators and start using 
type 2 locators so that locator size would be fixed, at least for the 
time being. We could use zeroed fields e.g. when a host does not want 
UDP encapsulation.

---

From: Miika Komu <[email-masked]>
Date: Thu, 25 Feb 2010 09:12:44 +0200

On 25/02/10 00:23, Ahrenholz, Jeffrey M wrote:

Hi,

>> The position of the LOCATORs varies at the Responder. RFC5206 place
>> it R1 whereas the NAT traversal extension places it in R2. While
>> both of the positions can be argumented, they introduce complexity
>> for the implementation. I would suggest simplifying this and just
>> place the LOCATOR parameter always to R2. This would exclude the
>> "load balancing" feature achieved by the LOCATOR parameter in the
>> R1 packet, but this is nothing that couldn't already be achieved
>> with DNS-based schemes.
>
> I'd agree with this... one of the complexities that I dislike about
> placing LOCATORs in the R1 is that every time your locator set
> changes (if including all addresses) or every time your preferred
> locator changes, you need to invalidate your entire R1 cache and
> recompute it. This would occur at a time when you are already
> (possibly) busy generating and processing UPDATEs for the locator
> change.

we had to implement this "workaround" as well.