On Wednesday 13 February 2008, [EMAIL PROTECTED] wrote:
> Hi,
>
> I have posted a new version of the ikev2-ipv6-config draft
> (http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-ipv6-config)
> which incorporates some new ideas based on good discussions
> in Vancouver (Hemant and Dave, thanks!).
>
> In particular, Section 5 has new text discussing the most important
> design choices to be made, and Appendix A has additional solution
> sketches for several design choice combinations.
>
> Section 6 still proposes the same solution as in draft version -01;
> that is, point-to-point link model where prefixes are assigned in
> IKEv2 configuration payloads, and access control is enforced by
> IPsec (traffic selectors in SAD/SPD). To me this seems to be the
> simplest solution -- however, the additional sketches in Appendix A
> should make it easier to compare different alternatives; and
> comments about them would be especially welcome!
Hello Pasi,
Thanks for updating your draft. I think this is useful work.
I have some comments below:
3.2. Link-Local Addresses
The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6
addresses of all types are assigned to interfaces, not nodes. [..]
All interfaces are required to have at least one Link-Local unicast
address".
Currently, the virtual interface created by IKEv2 configuration
payloads does not have link-local addresses. This violates
[IPv6Addr] and prevents the use of protocols that require link-local
addresses, such as [MLDv2].
Here you could mention DHCPv6 as well (and you are in Section 3.5, with
DHCPv6 PD). If one has a link-local address, it can use DHCPv6 to
retrieve various configuration parameters from the DHCPv6 server,
besides IPv6 address and DNS server address which are already handled
via the CFG_* exchange. That would allow to decouple introduction of
new configuration parameters from IKEv2 since only DHCPv6 support would
be needed.
3.4. Interface Identifier Selection
In the message exchange shown in Figure 2, the gateway chooses the
interface ID used by the client. It is also possible for the client
to request a specific interface ID; the gateway then chooses the
prefix part.
This approach complicates the use of Cryptographically Generates
Addresses [CGA]. With CGAs, the interface ID cannot be calculated
before the prefix is known. The client could first obtain a non-CGA
address to determine the prefix, and then send a separate CFG_REQUEST
to obtain a CGA address with the same prefix. However, this approach
requires that the IKEv2 software component provides an interface the
component managing CGAs; an ugly implementation dependency that would
be best avoided.
nit: s/an interface the/an interface to the/
4.1. Main Requirements
[...]
o A VPN client can be assigned multiple prefixes for use on the
client-gateway link. The client does not have to know beforehand
how many prefixes are needed.
[...]
o It should be possible to share the VPN access over a local area
network connection, without requiring anything special from other
hosts in the local network (beyond minimal IPv6 node requirements
specified in [RFC4294]).
These two requirements turn into the ability for client to be delegated
prefixes while not assigning them to the client-gateway link. They
could then be included in the negotiated TS's and routed appropriately
by the gateway to the client.
The ability to do prefix delegation with DHCP within the IPsec tunnel
interface could be useful for NEMO prefix delegation. Right now it is
not possible to use DHCP PD out of the box for NEMO prefix delegation
since multicast DHCP messages cannot be sent through an IPsec tunnel
between the NEMO Mobile Router and the Home Agent.
--julien
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
