[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new AH spec
Dan,
> This isn't _quite_ accurate.
>
> Destination options CAN appear before or after AH. But the semantic of
> destination options is very precise. From RFC 1883...
>
> IPv6 | Hop-by-Hop | Destination | Routing | Fragment....
>
> If Destination options appear before AH, they appear before the routing
> header. The semantics being that the destination options are parsed on each
> hop specified in the routing header. This might be hairsplitting, but others
> who are IPv6/IPsec implementors might get confused.
>From RFC 1883:
< IPv6|Hop-by-Hop|Destination|Routing|Fragment|AH|ESP|Destination|ULP
When Destination options appear before the Routing Header, they are
processed at each cluster contained in the Routing Header (including
the final destination), as described. When they appear after any AH
or ESP, they are only processed by the final destination after the AH
and/or ESP processing.
The text in the draft is pointing out an extensibility issue. It is
often hard to foresee what evolution may happen in the future. Some
option, which may be defined in the future, may have an effect that
alters how the AH or ESP is to be processed by the final destination.
Such an option could not appear before the Routing Header (as it
should not be processed at each cluster), and could not appear after
the AH and/or ESP as that would be too late to have the intended
effect.
For example, there is a Destination option that effectively alters the
"source" and "destination" "addresses" which are to be use further up
the protocol stack, e.g., as used in TCP or UDP "pseudo headers". As
currently defined, the SPI is relative to the "destination address".
There is no restriction on how an implementor must manage the SPI
number space. I.e., an implementor may have a single SPI space per
box, or may have one per interface, or even separate spaces for link
addresses and global addresses, etc., and then there is multihoming,
and the idea of having border routers rewriting addresses of packets
that pass through them. There are many issues to be worked out
(hopefully we can get the spec out before they are all resolved :-).
Lets not write extra code to eliminate flexibility that we might find
we want further down the road.
Charlie