Maybe $$v_{putter}(s)$$ would have been more accurate

Abbreviation "re" is never used

Forgotten to reflect in Figure 3.3 (lower)

Solution to this exercise can be later verified with definition (3.14)

This is a typo and should have been RFC 6775

if AdvValidTime > 2 || AdvValidTime > RemainingLifetime: set to AdvValidTime else if RemainingLifetime <= 2: ignore AdvValidTime else: set (decrease) to 2 the last 2 lines of which can be condensed to else: set to min(2, RemainingLifetime) Unit: hours

Read this text with emphasis on "any". I.e. the term "MAC-48" also includes locally administered MAC addresses (U/L bit set to 1), EUI-48 doesn't.

Unfortunately, there doesn't seem to be a term like "MAC-64" to refer to same for a EUI-64.

That's because the /64 customers are for the router IPs. WAN link: https://www.ripe.net/publications/docs/ripe-690/#4-1--numbering-the-wan-link--interconnection-between-the-network-and-the-end-user-cpe-

From https://doi.org/10.1145/3487552.3487829

Directly related: https://www.rfc-editor.org/rfc/rfc8978.html https://datatracker.ietf.org/doc/draft-ietf-6man-slaac-renum/

Source: some CDN and RIPE Atlas. they can detect dual stack Figure 1: assignment durations Figure 6,7: What prefix lengths ISPs delegate

Couldn't the personal firewall just respond with the same ICMP messagt to unsolicited packets? Although it would still decrease the hop count by one. But the sender (the personal firewall) can just increase the hop limit by that number.

Maybe they wanted "00" to be the default. For no special reason...

Linux (according to sysctl doc) just uses 600 seconds (as absolute value, probably derived from 0.6 * TEMP_PREFERRED_LIFETIME) as default value for this. The RFC doesn't even allow changing it.

Isn't the address deleted in an event of a network disconnect anyway? Hmm, Linux has keep_addr_on_down sysctl option.

``` 2s + (3x * (1x * 1s)) = 2s + 3s = 5 seconds

values from the referenced documents: DupAddrDetectTransmits: default: 1x RetransTimer: default 1s Ethernet doesn't override any of these values ```

The following concepts are used before they're explained. - DESYNC_FACTOR - REGEN_ADVANCE

For the same reason as https://datatracker.ietf.org/doc/html/rfc8981#section-3.4-3.5

!

If that's a problem, use DDNS.

https://en.wikipedia.org/w/index.php?title=Organizationally_unique_identifier&oldid=1190755293#64-bit_extended_unique_identifier_(EUI-64):~:text=of%20the%20form-,ccccccFFFEeeeeee,-and%20ccccccFFFFeeeeee%20are

But this mapping is used here because it is used in https://datatracker.ietf.org/doc/html/rfc4944#section-6:~:text=if%20no%20PAN%20ID%20is%20known

And their usage defined in this document overrides https://datatracker.ietf.org/doc/html/rfc4291#:~:text=Links%20with%20Other%20Kinds%20of%20Identifiers

So different prefix but resulted in same address

i.e. both nodes failing DAD, so none of them using the tentative addr. (defined as DAD failure in section 5.4.3, last bullet)

Not more info than in the RFC

Explanation:

TEMP_VALID_LIFETIME - TEMP_PREFERRED_LIFETIME < 1 second

In this mentioned unfortunate case, the connection would be made less than 1 second before expiry.

Full context: It would, upon expiry of the valid lifetime, just never enter a deprecated state, where it could keep existing connections open, but be immediately deleted.

Implemented as DESYNC_FACTOR

So another secret to store

don't forget

Although if you're continuously monitoring, chances are high you can even track IP address changes.

Assuming that - there are only so many devices that at most one at a time is detected to have changed its IP address. - it's the same device, not a new one.

e.g. IPv6 over PPP https://datatracker.ietf.org/doc/html/rfc5072#page-14

methods for choosing the tentative interface identifier

:

If a good source of uniqueness cannot be found, it is recommended that a random number be generated.

called FCrDNS

e.g. mail servers

Or rather however long their dial-up line session is

Only Figure 12 shows that this is indeed the distribution (for 99%)

Otherwise, I think that's only one possible distribution matching Figure 11. And still, like the author's mentioned analysis of Figure 9, under assumption of equal distribution.

"Under premise of equal distribution (of both groups: IPv4 and IPv6)" - Interesting wording and probably the only one you can make from an ECDF graph.

Figure 10 actually conveniently shows that this conclusion (under the simplifying assumption) is false, as ~1% resolvers have >50% IPv6-to-IPv4 ratio (p99 = 0.5).

Description: The graph shows that resolvers overall have more IPv4 than IPv6 egress IP addresses. - ~99% of resolvers have about at most 10 IPv6 addresses only. - The top 20% of resolvers with most IPv4 egress addresses have >80 IPv4 egress addresses.

"Amount" is more appropriate word

So far, the paper has interesting references

Spoiler: Was just Tor IP addresses on a shared cloud netblock (Akamai).

The paragraph continues to elaborate on the impact of data breach of a consumer business website. However, blocking these websites from the company network wouldn't help prevent this data breach. -> Going offtopic

Probably because of load balancing

That's WHOIS data (inetnum)

Because WHOIS was used when DNS should have been used.

Originally from https://dergipark.org.tr/tr/download/article-file/2963090 via https://dergipark.org.tr/tr/pub/tbbmd/issue/80549/1253700 via https://www.semanticscholar.org/paper/A-Study-on-the-nDPI-Deep-Packet-Inspection-Tool-%C3%96zbay-Dalkili%C3%A7/f069c9fbb86b5727ef9d13a130b496b803c92a12

Really unclear to me why they went into detail on these malware domains. - It just seems a coincidence that these domains resolve to bogons. - Identifying active infections is impossible with active DNS.

Typo, should be "don't swap"

Could these be domain transfers?

Attackers fault for token reuse

This being a convenient special case where you know the expected amount of payload data ahead, but oftentimes you don't know (e.g. TCP connection reuse).

But you could always redirect on start of the connection.

(I didn't read further, though.)

also references [8] and [9] are interchanged

;D

Typo, meant syndication

read "decoder for TLS SNI"

They meant "(4)"

:(

Because of amount of various zones, i.e.

The SURFnet name server we used is authoritative for approximately 10,000 DNS zone

Otherwise, for a single zone it's possible:

e.g. gov.uk NS -> IP addresses (v4/v6) are only 3 ASs, one of which is AS1103/SurfNet itself. The others ones being (and their looking glass being): - AS786/Jisc (lg.ja.net) - AS702/Verizon (see PeeringDB for LG. Even though Verizon has multiple ASs, this particular AS is selectable as location from the LG)

Re-check whenever Google changes its PoP prefixes.

Smells inaccurate, even at country level

transport layer protocol, not application layer protocol

For comparison: libprotoident does the first 4 bytes per direction

Actually, added

You mean "one account per phone number"

This whole document feels like it could have been written more compactly.

Discussed here (esp. this observation at this comment): https://serverfault.com/questions/1068301/base64-encoded-mx-records-in-txt-records#comment1393364_1068307

Filter term "National Internet Exchange of India" at https://www.iana.org/domains/root/db

(alternative 3rd party front: https://research.domaintools.com/statistics/tldpedia/) Also listed at https://en.wikipedia.org/wiki/.in#Internationalised_domain_names_and_country_codes

Can also be seen here visualized https://dns.coffee/zones/in

(Grammar: Probably meant "even though" instead of "either if")

I.e. if you query for "A" RR, BIND will - first query P(NS) (by the notation used in Table 4) (this query being as usual) - store this, P(NS), in cache - then query P(NS) for "NS" RR (query for C(NS)) - not store this, C(NS), in cache - then query on these NSs (C(NS)) for "A" RR (C(A)).

They probably meant "it sends the child an explicit NS query".

Seems so: - This word makes sense esp. in conj. with the provided reason "to retrieve more authoritative information". (Since there are only parent and child involved, the child being more authoritative since it is the actual nameserver in question) - And also: "the name server information retrieved and used in the following query is the one provided by the child" - whole logic of the remaining 8 line paragraph block

It doesn't matter how the resolver asks the parent for the auth. nameservers. As long as they get them, that would not affect the result of this experiment. (How the resolver asks would be rather related to QNAME minimization.)

referring to §4.1 "Disjoint Parent and Child NSSet"

Only about 40 vantage points receive data from the name servers in the child NSSet, indicating their resolvers likely performed explicit NS queries.

And shortly before, the setup was explained:

Only if resolvers perform explicit NS queries will they learn about [ns2,ns4].

([ns2,ns4] being said child NSSet)

Not entirely sure what sharing upstream caches means. Just a shared cache (when resolver IPs belong to the same resolver service)? If so, the "or" is probably meant as "and possibly".

Server responds REFUSED status code (code 5) or does not respond at all if there is no DNS server anymore

I think this only applies to case (ii)

I think they meant case (iii)

It's just nlnetlabs.nl vs internet.nl, why does this cause a different behavior?

...

They do have this feature vector output of the vision model (link), but still:

This feature vector is uninterpretable to us

In the end, for their problem, they used "KL-divergence loss" to filter out simulator artifacts (direction of image warp) from the feature vector, at train-time. This does not seem applicable for this case, though.

"We use a type of MHP loss, to make sure the model can predict multiple possible trajectories." - https://blog.comma.ai/end-to-end-lateral-planning/ (cites [17])

Doesn't this cover it?

https://blog.comma.ai/end-to-end-lateral-planning/:

For any large movements this seriously distorts the images

1/30 of a second, i.e. 1 frame

Assumption or tested? Explained in comma.ai blog that is referenced in footnote (link):

a model that just predicts a human’s most likely trajectory does not predict how to recover from mistakes

They mean the model wouldn't even find back onto lane through the lane markings because it wasn't trained with such cases?

Namely here: https://blog.comma.ai/end-to-end-lateral-planning/ ("we just apply a simple warp to the image")

😄

Afaik, it's not because openpilot misplanned something, it just expects the driver to help in applying steering force (torque), which because of car limitations it can't do by itself. Whether this is the case depends on your car.

Since when is meters per second a unit for distance? This should've been meters only.

train and test

Mapillary

Hence the name "dual-model deployment framework"

Which is which? origin = Supercombo, extra = OP-Deepdive (i.e. the reconstructed one)

typo, should be "dual" Occurs twice in document.

They could have plotted that :) Plotted it myself then.

Causing it to have no sense for warping, therefore ignoring it.

How do you ensure that it actually strips out (does not forward) the information about the warp direction? How does such a training process look like?

Ahh, see later:

Unfortunately, our tests indicate this vector does still contain information about how the image is warped. To remove that information [...]

Why is that? The trajectory seems right, so who's at fault? The car controller in determining the steering angle?

Explained later:

even in a simulation where we don’t introduce noise, there are linearization errors, model prediction errors, rounding errors, etc…

Isn't it called MTP?

A play on outsourcing.

Came in https://blog.comma.ai/090release/

Promo video: https://twitter.com/comma_ai/status/1595235027960225793