Christian Hopps <cho...@chopps.org> wrote:
> 1) WRAP still requires a next-header/protocol number. Additionally it
> would reduce bandwidth, is not widely implemented, and ultimately is
> not a great fit as it's trying to solve a different problem (allowing
> more packet inspection).
> 2) We could technically overload/re-use an existing IP protocol number
> that we assume will never be used as an ESP payload, but this is a
> sub-optimal solution as it disallows the re-use of IPTFS framing
> outside of ESP. Ultimately this can serve as a backup solution that
> aligns with (and thus supports) this (temporary) early allocation
> request.
> So can we move forward with the early allocation request?
I would agree. The WG should go ahead with the early allocation request.
It still needs AD approval, and then goes to the IESG.
I think that the WG has agreed:
1) we need a number.
2) we'd like the number via early allocation
3) we have rough consensus that there are a set of protocol numbers
that we *could* reuse, and I think that we could make a list
of protocol numbers we know we can *not* reuse.
(4,6,17 would start the list we can not use)
so let's put the allocation request in, and let's let the IESG decide how
much they want to optimize the protocol space.
I think that we have consensus that our need for uniqueness is not as strong
as other users. BUT simplificity of accounting and coding would make it
simplest if the number was not something already in use.
But, we are not out of protocol numbers, and I think that if it comes to
recycling
numbers, that maybe there are many low-hanging fruit as candidates.
[13-16,18-26 comes easily to mind]
Also, if the IESG wanted to mark WRAP as returned, that's a different
discussion as well.
--
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
