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]/
[ipv6-wg] Re: not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD
- Previous message (by thread): [ipv6-wg] Re: not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD
- Next message (by thread): [ipv6-wg] Reminder: Global IPv6 Deployment Monitoring Survey 2011
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Roesen
dr at cluenet.de
Tue Jul 26 10:29:39 CEST 2011
On Tue, Jul 26, 2011 at 09:05:25AM +0200, Christian Seitz wrote: >> Send those ICMP messages from a globally reachable IP address. The source >> address doesn't matter, after all. > > so Level3 should fix the problem in this case? Surely not. There is nothing to fix, they don't do anything wrong. The problem is indeed that the IXP prefix is not advertised, which is inherently incompatible with any uRPF (and exactly the reason why you see e.g. 2001:7f8:2c::/48 in the DFZ since 2004 :-)). >> From 2001:7f8:4::d1c:1 icmp_seq=1 Packet too big: mtu=1450 Die Adresse ist korrekt. Siehe RFC4443: =================================================================== 2.2. Message Source Address Determination A node that originates an ICMPv6 message has to determine both the Source and Destination IPv6 Addresses in the IPv6 header before calculating the checksum. If the node has more than one unicast address, it MUST choose the Source Address of the message as follows: (a) If the message is a response to a message sent to one of the node's unicast addresses, the Source Address of the reply MUST be that same address. (b) If the message is a response to a message sent to any other address, such as - a multicast group address, - an anycast address implemented by the node, or - a unicast address that does not belong to the node the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node. The address SHOULD be chosen according to the rules that would be used to select the source address for any other packet originated by the node, given the destination address of the packet. However, it MAY be selected in an alternative way if this would lead to a more informative choice of address reachable from the destination of the ICMPv6 packet. =================================================================== And the address which would be selected as "source address for any other packet originated by the node, given the destination address of the packet" is quite usually the interface IP of the egress interface towards the ICMP packet destination. Asking L3 to change that (if they could at all) is unreasonable IMHO. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
- Previous message (by thread): [ipv6-wg] Re: not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD
- Next message (by thread): [ipv6-wg] Reminder: Global IPv6 Deployment Monitoring Survey 2011
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]