Hi, i have a question about code 5 error: would the ICMP error message contain the suggested source address (or prefix that has to containe the source address)
I mean, in the case that the packet is discarded becuase the source address is not compatible with the ingress filtering, the router that discards the packets probably knows which are the accepted prefixes, so it would be interesting to use the message error to inform the host about the correct prefix to use for this particular destination. Have you considered something about this? thanks, marcelo > -----Mensaje original----- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de > [EMAIL PROTECTED] > Enviado el: viernes, 30 de enero de 2004 2:31 > Para: [EMAIL PROTECTED] > Asunto: ICMPv6: New destination unreachable codes > > > Hi, > > I have added 2 new destination unreachable codes that > Bob suggested in the ICMPv6 draft. > > (me and Bob had a discussion offline and the text is > outcome of that) > > Here is the new text. I would appreciate everyone's > comments. > > ============== > ICMPv6 Fields: > > Type 1 > > Code 0 - no route to destination > 1 - communication with destination > administratively prohibited > 2 - beyond scope of source address > 3 - address unreachable > 4 - port unreachable > 5 - source address failed ingress policy > 6 - reject route to destination > > Unused This field is unused for all code values. > It must be initialized to zero by the sender > and ignored by the receiver. > Description > > A Destination Unreachable message SHOULD be generated by a router, or > by the IPv6 layer in the originating node, in response to a packet > that cannot be delivered to its destination address for reasons other > than congestion. (An ICMPv6 message MUST NOT be generated if a > packet is dropped due to congestion.) > > If the reason for the failure to deliver is lack of a matching entry > in the forwarding node's routing table, the Code field is set to 0 > (NOTE: this error can occur only in nodes that do not hold a "default > route" in their routing tables). > > If the reason for the failure to deliver is administrative > prohibition, e.g., a "firewall filter", the Code field is set to 1. > > If the reason for the failure to deliver is that the destination is > beyond the scope of the source address, the Code field is set to 2. > This condition can occur only when the scope of the source address is > smaller than the scope of the destination address (e.g., when a > packet has a link-local source address and a global-scope destination > address) and the packet cannot be delivered to the destination > without leaving the scope of the source address. > > If the reason for the failure to deliver can not be mapped to any of > the specific codes listed above, the Code field is set to 3. The > example of such cases are inability to resolve the IPv6 destination > address into a corresponding link address, or a link-specific problem > of some sort. > > One specific case in which a Destination Unreachable message with a > code 3 is sent is in response to a packet received by a router from a > point-to-point link, destined to an address within a subnet assigned > to that same link (other than one of the receiving router's own > addresses). In such a case, the packet MUST NOT be forwarded back > onto the arrival link. > > A destination node SHOULD send a Destination Unreachable message with > Code 4 in response to a packet for which the transport protocol > (e.g., UDP) has no listener, if that transport protocol has no > alternative means to inform the sender. > > If the reason for the failure to deliver is that packets with this > source address is not allowed due to ingress filtering policies, the > Code field is set to 5. > > If the reason for the failure to deliver is that the route to the > destination is a reject route, the Code field is set to 6. This may > occur if the router has been configured to reject all the traffic for > a specific prefix. > > Upper layer notification > > A node receiving the ICMPv6 Destination Unreachable message MUST > notify the upper-layer process. > ============== > > Regards > Mukesh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
