Re: [Anima] Is this how BRSKI/IPIP works?

[Brian E Carpenter <[e-mail]>]

On 15/07/2017 09:44, Michael Richardson wrote:
> 
> Brian E Carpenter <[e-mail]> wrote:
>     >> Brian E Carpenter <[e-mail]> 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