[IPsec] IPsec tunnels *can* be fully-featured "interfaces" (sec 3.15.3)

[Dan McDonald <danmcd at sun.com>]

Let me quote from section 3.15.3 of IKEv2bis:

	IPsec tunnels configured using IKEv2 are not fully-featured
	"interfaces" in the IPv6 addressing architecture sense [IPV6ADDR].
	In particular, they do not necessarily have link-local addresses, and
	this may complicate the use of protocols that assume them, such as
	[MLDV2].

My issue lies with the assertion that tunnels configured using IKEv2 (and its
CFG_* payloads) are not fully-featured interfaces.  What is to prevent an
implementation from creating a fully-formed network interface fro the result
of an IKEv2 Configuration exchange?  I grant that both sides (IRAC/IRAS) need
to cooperate in this regard, BUT I do not see any reason to exclude the
possibility.

Consider the fully private network with access points attached to the
Internet.  An IRAC and conspiring IRAS can have an agreement on how an IRAC
derives its link-local address.  E.g. we have a non-IKE-payload, but
IKE/IPsec-protected remote-access deployment that uses the
assigned-inner-IPv4 to derive the link-local IPv6, and then we run neighbor
discovery as if it were a PPP link.  Even if we didn't assign the client an
inner IPv4, we could have IKEv2's CFG_REPLY (or our equivalent thereof)
assign a link-local, and then let IPv6 neigbor discovery and addrconf take
over from there.

My point is, there may not be limitations in configuring IPv6 addresses -- at
least not from the POV of a spec.  Now implementations may have issues, but
that's not the concern of a spec, right?

Dan
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec