Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
> I have aligned my Python demos** of the BRSKI discovery mechanisms with
> the -12 draft.
> Here are dumps of the received flood messages, with discussion:
> (1) Flood sent by the registrar as received by the proxy. This is Python
output
> (so the b'...' strings are hexdumps of bytes objects.)
> [9, 1729214102, b'2406e00741ec000128ccdc4c97036781', 120000,
[['AN_join_registrar', 5, 255, 'EST-TLS'], [103,
b'2406e00741ec000128ccdc4c97036781', 6, 80]]]
> Nothing serious to report here. Since the draft only defines the 'EST-TLS'
> form, I haven't included any alternatives. My code could also handle
announcing
> IP-in-IP for example.
> Compare to the example in the draft:
> [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000,
> ["AN_join_registrar", 4, 255, "EST-TLS"],
> [O_IPv6_LOCATOR,
> h'fda379a6f6ee00000200000064000001', TCP, 80]]
> I'd prefer to see TCP represented as IPPROTO_TCP to align with the
> GRASP spec.
I think that what I did was confuse some of the abstract and specific value.
Because things like M_FLOOD and O_IPv6_LOCATOR are symbolic representations
of numbers, while TCP was just something that I thought I could abstract
myself.
I've changed it to say IPPROTO_TCP everywhere.
> [9, 160559994, b'2406e00741ec000128ccdc4c97036781', 180000, [['AN_proxy',
5, 1, ''], [103, b'fe8000000000000028ccdc4c97036781', 6, 11805]]]
> Compare to the example in the draft:
> [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
> ["AN_Proxy", 4, 1, ""],
> [O_IPv6_LOCATOR,
> h'fe800000000000000000000000000001', 'TCP', 4443]]
> Several comments:
> 1. The 3rd element is the 'initiator' address. The draft shows that as
> a link-local. It doesn't matter too much, but my code uses a routeable
> address. It's only there for disambiguation in a multi-hop flood,
> which doesn't apply in this case. The address that matters is the second
> one, in the locator. The packet itself is sent link-local.
Since it's a link-local, DULL single-hop "flood" that can never get forwarded
in any way, and the it's occuring on the "bare" wire, using any GUA (or ACP
ULA) would seem to leak information that should remain safely inside the ACP.
> 2. 'TCP' shouldn't be a string, it should be IPPROTO_TCP as above.
Agreed.
> 3. The objective is defined as having a null value. Why isn't it
> "EST-TLS" again?
I'm not sure, I thought that the objective-value was what we were looking
for. I.e. if some device is trying to find a place to backup 1GB,
then it might have an objective of "KERNEL:DUMP" with an objective-value
of 1073741824.
Since we don't care what the dimension of the objective, I thought leaving it
empty was the best thing.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
