Re: [IPsec] INTERNAL_IP6_ADDRESS for link local address assignment

[Tero Kivinen <kivinen at iki.fi>]

Julien Laganier writes:
> 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,
> >
> > Agreed.  (And isn't this what I mentioned earlier on this list?)
> 
> 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). 
-- 
kivinen at safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec