Re: revised IPsec processing model

[Stephen Kent <kent@bbn.com>]

At 19:59 +0900 7/19/03, itojun@iijlab.net wrote:
>  >>	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

Thanks for the additional info. As Bill & Markus pointed out, the VID 
is not the same as an address, in the sense discussed above. It is an 
identifier largely internal to IPsec. Does Bill's suggestion of how 
to accommodate the VID address your concerns?

Steve