Re: revised IPsec processing model

[itojun@iijlab.net]

>>	in that case, i would like to express concern w/ IPv6 linklocal address
>>	(the latter paragraph of mine).
>Could you elaborate a bit more on the nature of the problem? Your 
>paragraph above was not enough for me, since I don't understand what 
>IPv6 does in this regard absent Ipsec.  Also, in which of the IPv6 
>specs is the behavior you are describing defined?

	RFC2460/2373.  draft-ietf-ipv6-scoping-arch-00.txt will also give you
	more information.

	with IPv6, there are not-universally-unique address defined in RFC2373.
	one of them is link-local address (the other one, site-local address,
	is going away so i will omit site-local from the discussion).
	link-local address range is fe80::/10, and address under it is unique
	on a certain link only.  for instance, the following situation is
	legal:

	fe80::1
	  |
	==+===== ether segment1
	  |
	your machine
	  |
	==+===== ether segment2
	  |
	fe80::1

	i.e. you are seeing the same address (fe80::1) on the different link
	your machine is attached to.  to disambiguate these machines, socket
	API (RFC2553) has additional field, sin6_scope_id, in sockaddr_in6.
	specifying 128bit address (fe80::1) is not enough, you have to specify
	which link you are talking about (textual notation is
	"fe80::1%segment1").


	now, many implementations use interface to identify link.  BSD-based
	implementation normally disambiguates incoming packet by
	m->m_pkthdr.rcvif.

	by introducing "virtual interface" and switching m->m_pkthdr.rcvif
	based on the virtual interface, you will become unable to identify
	peer correctly - after IPsec processing, both "fe80::1%segment1" and
	"fe80::1%segment2" would become "fe80::1%ipsec".  providing 1-by-1
	mapping between virtual interface and real interface does not provide
	a solution, since you will now see non-IPsec traffic as sent from
	"fe80::1%segment1" and IPsec traffic as sent from "fe80::1%ipsec1",
	and upper layer will get confused.

itojun