Samofatov, Nickolay wrote:

>Hi, Jim, All!
>
>
>
>> fb_dpb_ip_path <total length> <count byte> <ip address list>
>>
>>
>
>I implemented this piece in my tree some time ago to support Trace API
>functionality.
>The difference of implementation is that IPv4 is not the only protocol
>supported by the design.
>IPv6 address is longer, SSL certificate header is much longer.
>
>

It sounds like more internal structure for a connection description is
necessary. Could you describe what you implemented in more detail?

>IPv4 addresses can almost always be forged and in many cases cannot be
>trusted for security purposes.
>
>

Are you sure that's true? The IP address comes from the socket
information. If it has a forged IP, how can the connect get established
in the first place?

>Repeating structure in mentioned block (isc_dpb_address_path) is
>consisted of protocol identifier, address block length and address block
>containing protocol-specific address in human-readable form suitable for
>matching.
>
>

I'm wary about "human readable form". The binary API is for the
convenience and simplicity of the implementations. I'd rather the
underlaying implementation be aware of the differences between IPv4 and
IPv6 and behave accordingly than to obscure the semantics for pattern
matching. Pattern matching, to my taste, favors one form of usage at
the expense of others. And in most cases, it's much easier to turn a
canonical representation to human readable form than to turn human
readable stuff into a canonical representation. But lets see what you have.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376



[Non-text portions of this message have been removed]