<t...@cs.fau.de> wrote:
> But also remember that the original spirit of rfc4301 (i hope i state
this correctly)
> is not that of "tunneling", but rather of authenticating/encrypting
packets. This
> is reflected in the SPD that allows you to specify some subsets of
packets to
> which you apply this security. So address resolution itself would in most
traditional
> implementations (at least the ones i know) still see the underlying type
of interface
> and use its address resolution method and formats (eg: Ethernete,
> ARP/ND,
It's a great thought, but it's not implemented for reasons that wind up
devolving into "we don't have a global PKI", (with a bunch of "the customer
didn't ask for that" in the middle)
> There could still be some RFC specifying how to build a virtual
> "pseudo-multicast" enabled "NBMA" subnet using a bunch of underlying
> p2p subinterfaces and how to ND in that case. So maybe i should ask on
> 6man.
RFC6550 is such a specification.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
