[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: revised IPsec processing model
>> 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