Christian Hopps writes: > Dear ipsecme Chairs, > > This request is inline with the guidelines as set forth in RFC7120 > (https://tools.ietf.org/html/rfc7120) > > I would like to request early allocation of the IP protocol number > [A] used for the ESP payload identifier for IPTFS (suggested value > is 144 or next available) as documented in > https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01 [B] > > This will aid in the deployment of an experimental implementation of > the documented protocol as well as testing inter-operability with > other expected implementations. [C], [D] > > In addition to these RFC7120 reasons, the topic was raised on the WG > list and discussed in previous meetings. The discussions highlighted > that early allocation was a good choice as it allowed for the > temporary assignment and an extended period of time for adequate > review (and explanation if needed) of this allocation prior to > publication requested being reached.
I am bit concerned about this. First of all, as far as I understand for IPsec we do not need real IP protocol number, as the number we are using is never going to appear anywhere in the actual IP packet header, it only appears in the ESP trailer Next Header field. Note, that the ESP Next Header field is not exactly same as IP Protocol Numbers, it is: The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or a next layer header and data. The value of this field is chosen from the set of IP Protocol Numbers defined on the web page of the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 indicates TCP. i.e., it is separate set of numbers, which happen to mostly match what IP protocol numbers use, but we also interpret some values differently, for example value 59 (IP protocol no next header) is used to indicate dummy packet etc. We could easily use similar trick than what we use for dummy packets for this too. Also there is warpped ESP which would allow us to use that, which would again allow us to do things without allocating new IP protocol number. We had some discussion about this in the mailing list earlier, but I didn't think that there was really a final result from that discussion (or I might be remembering wrong, as I didn't have too much time to participate that discussion at that time). The reason I am concerned is that I was there when we wanted to get the Wrapped ESP IP protocol number, and there was quite a lot of discussion going on at that time, and it was not just we send request, and we get the number. Of course at that point I also supported proposal which did not require new IP protocol number, so for me the problems getting IP number was for my favor :-) Anyways before we commit resources and try to get the IP protocol number I want to make sure we actually need it, and we have good responses to why we cannot do it with the other ways I presented above. I would assume those questions are going to be asked from chairs or area directors during the process anyways, so we need to have good answers to them ready (and for me it would be quite hard to explain why we cannot use warpped ESP, or dummy packet trick as I think we can do those and we do not need IP protocol number). Note, that if the answer is going to be that we want to use this also when we are not using IPsec, then this is even bigger can of worms, as that would most likely mean that this work does not belong to the IPsecME working group, but should be part of completely different area... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
