[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TOS copying considered harmful
itojun@iijlab.net wrote:
>
> >> Having two specifications for packets with protocol type 4 inside IP
> >> should be avoided if at all possible.
> >Now this I agree with. Especially since the IPsec RFCs themselves seem to
> >be very confused about this.
>
> for reference, here's a little list of specs which talks about
> protocol type 4/41 encapsulation. not sure if it is complete.
> (from KAME sys/netinet/ip_encap.c)
This, together with Harry's earlier observation that Assigned Numbers
points back to 2003 regarding IP protocol type = 4, are very good
reasons for incorporating as much as possible into 2003bis.
Regarding Ran's note about IPSEC, I'm proposing only that 2003bis allow
everything that IPSEC requires, so that when IPSEC refers to tunneling,
it can say "implement 2003bis", and then put additional _restrictions_,
e.g., regarding the copying or not of the TOS and DF bits.
It's fine for subsequent documents to limit optional components of a
spec.
> * Here's a list of protocol that want protocol #4:
> * RFC1853 IPv4-in-IPv4 tunnelling
> * RFC2003 IPv4 encapsulation within IPv4
> * RFC2344 reverse tunnelling for mobile-ip4
> * RFC2401 IPsec tunnel
2003 is the one that's recognized in Assigned Numbers, as Henry noted
earlier.
1853 is effectively superceded by 2003, even though it's only implicit
(in the Acks of 2003)
2344 refers back to 2003; a new variant is not proposed
it is only 2401 that conflicts with 2003, and only on TOS and DF
2003bis should discuss the clearing of these bits as an option, and
discuss the implications of using that option, precisely because it is
needed, e.g., for 2401 (or 2401bis).
Then 2401bis can refer back to 2003bis for the specification of the
tunnel headers, and indicate that 'clearing the bits' may be required
for security reasons, and that it can use exactly the header specified
by 2003bis.
Joe
Follow-Ups:
References: