This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] Mandating NAT toward the final /8
- Previous message (by thread): [address-policy-wg] Mandating NAT toward the final /8
- Next message (by thread): [address-policy-wg] Mandating NAT toward the final /8
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Masataka Ohta
mohta at necom830.hpcl.titech.ac.jp
Fri Jul 17 10:38:40 CEST 2009
Florian Weimer wrote:
> The joke is in RFC 4294 (sections 4.5.4 and 8 in particular).
My favorite joke of IPv6 is in RFC4443:
(e) An ICMPv6 error message MUST NOT be originated as a result of
receiving the following:
(e.3) A packet destined to an IPv6 multicast address. (There are
two exceptions to this rule: (1) the Packet Too Big Message
(Section 3.2) to allow Path MTU discovery to work for IPv6
multicast, and (2) the Parameter Problem Message, Code 2
You can send a 1500B packet with a forged source address of DDoS
target to a multicast group with huge number of receivers using
PPPoE at their last hops.
As for feedback, I warned IPv6 WG about the problem, twice.
Some sane people will completely disable and filter out "Packet
Too Big Message"s including those against unicast packets.
And there should be other jokes not all of which is recognized
by operators.
Masataka Ohta
- Previous message (by thread): [address-policy-wg] Mandating NAT toward the final /8
- Next message (by thread): [address-policy-wg] Mandating NAT toward the final /8
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]