Subject: Re: [hiaps] Host identifiers

From: <[email-masked]>
Date: Mon, 2 Dec 2013 09:50:49 +0100

Dear all,

I tend to agree with Dan that in our case the Host_id needs not to be the full IP address but 'must [only] be unique to each host under the same shared IP address' (RFC 6967) - so given that this shared address is available, only e.g. those 8 bits are required for complete identification.

However assuming a 'mobile scenario' the point of attachment (providing that shared IP address)  may change and at each such a handover the Host_id might have to change too. To prevent frequent change and follow-up signaling we could try to re-use considerations in HIP (RFC 4423) (public key) or in RFC 3986 (URI) .... and we would presumably end up in a more-byte consuming definition (such as full IP address).

What do you think?

Best regards
Dirk
-----Original Message-----
From: hiaps [mailto:[email-masked]] On Behalf Of Dan Wing
Sent: Donnerstag, 28. November 2013 01:24
To: [email-masked]
Cc: [email-masked]
Subject: Re: [hiaps] Host identifiers

On Nov 27, 2013, at 12:07 PM, Behcet Sarikaya <[email-masked]> wrote:

> Hi all,
> 
> I would like to ask a simple question and hopefully open up a discussion: what is host identifier or HOST_ID? 
> 
> In RFC 6967, it is defined as:
> 
> due to address sharing, servers need
>    extra information beyond the source IP address to 
>    differentiate the
>    sending host.  We call this information the HOST_ID.
> The answer seems to be different for each use case. For prefix sharing, it is the sending host's IPv6 address. For hosts behind NAT, it is the sending host's IPv4 address.

It doesn't need to be the sending host's IP address.  For example, if all the hosts behind a NAT are in the 192.168.1/24 subnet, an 8-bit HOST_ID would be enough to uniquely identify each host behind the NAT, and no purpose in using 32 bits.  That is, the most significant bits of the IPv4 address are not necessary.  As another example, with an IPv6 client communicating to a NAT64, the most significant bits of the IPv6 address are not necessary (because all of the subscribers using an ISP's NAT64 belong to that ISP, and have been assigned IPv6 addresses from the ISP's own IPv6 prefix), and the least significant 64 bits of the IPv6 address are also not necessary (because IPv6 privacy addresses makes them pretty useless to identify a particular 'host').  So with NAT64 there are really about the same number of bits used to identify a 'subscriber' as with IPv4 -- which is not much of a surprise.

> What about other cases? For CGNs?

CGN is just a big NAT, so same use-case applies.  But need to think about impact of VRFs or VLANs or similar technology behind the CGN, which could mean there are multiple "customers" (users) with 192.168.1/24 subnets, but each connecting to that CGN using different VLAN (or VRF).  If those all share the same public IPv4 address, then HOST_ID would need to include the VRF/VLAN number (if all that is necessary is identifying the 'subscriber') and possibly also the subscriber host's IPv4 address (if the need extends to describing the host, too).

-d

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

---

From: <[email-masked]>
Date: Mon, 2 Dec 2013 10:00:26 +0100

Hi Dirk,

HIP can be used indeed, but this assumes every server is speaking HIP. This by far a non-viable assumption.

As for the discussion on the frequent change of the HOST_ID, the suggestion to use a permanent identifier will raise a lot of privacy discussion and objections.

IMHO before having solution-oriented discussion, let's see first if people understand well the problem space and the set of use cases identified so far. 

Cheers,
Med 

>-----Message d'origine-----
>De : hiaps [mailto:[email-masked]] De la part de Dirk.von-
>[email-masked]
>Envoyé : lundi 2 décembre 2013 09:51
>À : [email-masked]; [email-masked]
>Cc : [email-masked]
>Objet : Re: [hiaps] Host identifiers
>
>Dear all,
>
>I tend to agree with Dan that in our case the Host_id needs not to be the
>full IP address but 'must [only] be unique to each host under the same
>shared IP address' (RFC 6967) - so given that this shared address is
>available, only e.g. those 8 bits are required for complete identification.
>
>However assuming a 'mobile scenario' the point of attachment (providing
>that shared IP address)  may change and at each such a handover the Host_id
>might have to change too. To prevent frequent change and follow-up
>signaling we could try to re-use considerations in HIP (RFC 4423) (public
>key) or in RFC 3986 (URI) .... and we would presumably end up in a more-
>byte consuming definition (such as full IP address).
>
>What do you think?
>
>Best regards
>Dirk
>> The answer seems to be different for each use case. For prefix sharing,
>it is the sending host's IPv6 address. For hosts behind NAT, it is the
>sending host's IPv4 address.
>
>It doesn't need to be the sending host's IP address.  For example, if all
>the hosts behind a NAT are in the 192.168.1/24 subnet, an 8-bit HOST_ID
>would be enough to uniquely identify each host behind the NAT, and no
>purpose in using 32 bits.  That is, the most significant bits of the IPv4
>address are not necessary.  As another example, with an IPv6 client
>communicating to a NAT64, the most significant bits of the IPv6 address are
>not necessary (because all of the subscribers using an ISP's NAT64 belong
>to that ISP, and have been assigned IPv6 addresses from the ISP's own IPv6
>prefix), and the least significant 64 bits of the IPv6 address are also not
>necessary (because IPv6 privacy addresses makes them pretty useless to
>identify a particular 'host').  So with NAT64 there are really about the
>same number of bits used to identify a 'subscriber' as with IPv4 -- which
>is not much of a surprise.
>
>CGN is just a big NAT, so same use-case applies.  But need to think about
>impact of VRFs or VLANs or similar technology behind the CGN, which could
>mean there are multiple "customers" (users) with 192.168.1/24 subnets, but
>each connecting to that CGN using different VLAN (or VRF).  If those all
>share the same public IPv4 address, then HOST_ID would need to include the
>VRF/VLAN number (if all that is necessary is identifying the 'subscriber')
>and possibly also the subscriber host's IPv4 address (if the need extends
>to describing the host, too).
>
>-d
>