Subject: [IPsec] INTERNAL_IP6_ADDRESS for link local address assignment

From: Julien Laganier <[email-masked]>
Date: Wed, 17 Sep 2008 16:43:21 +0200

Folks,

draft-eronen-ipsec-ikev2-ipv6-config-04 introduces the INTERNAL_IP6_LINK 
configuration attribute (below) that provides the client with two 
parameters:

- a Link Identifier used by the client and VPN gateway to identify an 
IPv6 virtual link associated with one or more IKE SAs.

- an IPv6 Interface Identifier used by the client to configure its IPv6 
link-local address.

Since the Interface Identifier is only used to form an IPv6 link-local 
address (non-link-local addresses can be configured from the assigned 
prefixes and any interface identifier) it would be simpler that the 
client's IPv6 link-local address is assigned via the existing 
configuration attribute INTERNAL_IP6_ADDRESS, while the 
INTERNAL_IP6_LINK would contain the Link Identifier only.

What do you think?

--julien

> 7.1.  INTERNAL_IP6_LINK Configuration Attribute
>
>    The INTERNAL_IP6_LINK configuration attribute is formatted as
>    follows:
>
>                         1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    !R|         Attribute Type      !            Length             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                          Link-Local                           |
>    |                         Interface ID                          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    ~                        IKEv2 Link ID                          ~
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    o  Reserved (1 bit) - See [IKEv2].
>
>    o  Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1).
>
>    o  Length (2 octets) - Length in octets of the Value field (Link-
>       Local Interface ID and IKEv2 Link ID); 8 or more.
>
>    o  Link-Local Interface ID (8 octets) - The Interface ID used for
>       link-local address (by the party that sent this attribute).
>
>    o  IKEv2 Link ID (variable length) - The link ID (may be empty
>       when the client does not yet know the link ID).
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Dan McDonald <[email-masked]>
Date: Wed, 17 Sep 2008 10:56:49 -0400

> configuration attribute INTERNAL_IP6_ADDRESS,

Agreed.  (And isn't this what I mentioned earlier on this list?)

> while the INTERNAL_IP6_LINK would contain the Link Identifier only.
> 
> What do you think?
> 
NUKE>  |                          Link-Local                           |
NUKE>  |                         Interface ID                          |
NUKE>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    ~                        IKEv2 Link ID                          ~

So INTERNAL_IP6_LINK would remove the bits I have prefixed with NUKE> ?

I have another question, but I suspect reading the draft will answer it.

Thanks!
Dan

---

From: Julien Laganier <[email-masked]>
Date: Wed, 17 Sep 2008 17:51:14 +0200

On Wednesday 17 September 2008, Dan McDonald wrote:
> > Since the Interface Identifier is only used to form an IPv6
> > link-local address (non-link-local addresses can be configured from
> > the assigned prefixes and any interface identifier) it would be
> > simpler that the client's IPv6 link-local address is assigned via
> > the existing configuration attribute INTERNAL_IP6_ADDRESS,
>

Yes, this is one of the things you mentioned. 

> NUKE> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > ~                          IKEv2 Link ID                        ~

Right. And probably INTERNAL_IP6_LINK would become INTERNAL_IP6_LINKID.

> I have another question, but I suspect reading the draft will answer

All right then.

--julien

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 Sep 2008 13:13:29 +0300

> Yes, this is one of the things you mentioned. 

As long as the prefix itself is negotiated using the
INTERNAL_IP6_PREFIX this does not really matter. Either way is ok. Of
course this means the implementations need to be smart enough to
distinguish link local addresses from normal addresses.

This would again mean that server can remove the link-local address
from the client or change it, as when we are using the
INTERNAL_IP6_ADDRESS we are using the rules bound to it, meaning the
client only sends hints for the server and server replies back with
the accepted values. I already proposed that we should use that same
rule with INTERNAL_IP6_LINK attribute too, just to keep it sync with
other attributes. 

> Right. And probably INTERNAL_IP6_LINK would become INTERNAL_IP6_LINKID.

After this change the negotiation would come:

      CP(CFG_REQUEST) =
         { INTERNAL_IP6_LINKID(IKEv2 Link ID (or empty if first time))
	   INTERNAL_IP6_ADDRESS(Client's Link-Local Address)
           INTERNAL_IP6_DHCP() }
      TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
             FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
      TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
             FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)  -->

      CP(CFG_REPLY) =
         { INTERNAL_IP6_LINK(IKEv2 Link ID),
	   INTERNAL_IP6_ADDRESS(Client's Link-Local Address)
           INTERNAL_IP6_PREFIX(Prefix1/64),
           [INTERNAL_IP6_PREFIX(Prefix2/64),...],
           INTERNAL_IP6_DHCP(Address) ]
      TSi = ((0, 0-65535,
              <Client's Link-Local Address> -
              <Client's Link-Local Address>)
             (0, 0-65535,
              Prefix1::0 -
              Prefix1::FFFF:FFFF:FFFF:FFFF),
             [(0, 0-65535,
               Prefix2::0 -
               Prefix2::FFFF:FFFF:FFFF:FFFF), ...])
      TSr = (0, 0-65535,
             0:0:0:0:0:0:0:0 -
             FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

One problem with this could be that stupid old server implementation
would interpert that so that client only wanted the client's link
local address as its IPv6 address, and it would not allocate any other
address to the client.

In most cases even old servers would not allow client to use link
local addresses as their addresses, thus they would follow the rules
in the RFC4306 and take the interface id from the link local address,
and use that and replace the prefix with their own prefix they have
reserved for the IPv6 addresses and it would return real routable
address back on the INTERNAL_IP6_ADDRESS reply (and no prefixes or
link information as it is old server which do not support this
extension yet).

I think the first case of really stupid servers which do not verify
that the address client requested is usable is something that we do
not really need to care, as that server would not be usable in IPv6
case at all.

So I think this would be even bit better way to do this (especially as
it has even better backwards compatibility with existing
specification). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec