On 15/07/2017 09:44, Michael Richardson wrote: > > Brian E Carpenter <[email protected]> wrote: > >> Brian E Carpenter <[email protected]> wrote: > OK, I'm > >> getting there. More in line: > >> > >> >> 1) Registrar accepts any Lx1 as local. There is no precedent in v6 > >> >> APIs to open such a socket, but this actually supported on many >> > >> platforms. It's used for nasty stuff like transparent application >> > >> layer proxies, forced HTTP proxying, and the like. > >> > >> > I think there's a more subtle way to look at it. When the registrar > >> > receives a protocol 41 packet from a new ACP address, it > >> conceptually > synthesises a new virtual interface and assigns Lx1 as > >> its link local > address. On that interface, things would look > >> normal. Thus RFC2473: > >> > >> I can buy this. It argues that the Proxy should send a gratuitous > >> packet to the Registrar to prime that virtual interface. An ICMP echo > >> request perhaps. > > > Or a GRASP M_NOOP, designed for such purposes! > > I think that's also reasonable. > > >> How can we document this well? > > > I think it has to be spelled out almost at the pseudocode level. We had > > to spell out the encap/decap behaviour for 6to4 in some detail, and > > that was just about the only bit of 6to4 that never created trouble > > ;-). There are various encap/decap specs of that kind, and the NAT64 > > stuff also goes into horrible detail... > > okay. Are you suggesting the 6to4 document should be looked at for style?
Not especially. I'm more saying: if you can't write the equivalent of pseudocode, you can't expect other programmers to get it right. Maybe a really good example of a painstaking encap description is in IPsec: RFC4301 section 5.1.2 and its subsections. I don't think we need to go that far, but we need to be 100% unambiguous. All IMHO of course. Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
