Ron, There is no behavior in draft-ietf-spring-srv6-network-programming that proposes to encode a SID in the source address of the IPv6 header.
If in the future someone would propose to do such thing in another I-D; it is up to those authors to justify why they would want to do this, and how to ensure that the processing does not break any other protocol. But as said, this is not in the scope of draft-ietf-spring-srv6-network-programming. Regarding the ICMP messages: SRH follows RFC4443 Section 2.2 with respect to how to select the ICMP Source Address. SRv6 Network Programming does not change this (it simply follows the SRv6 rules defined by the SRH). In your email you refer to a possibility of future protocols breaking this. I don’t think that we can guess what future protocols will do, and it is up to those future protocols to ensure compatibility with the existing standards. Thanks, Pablo. From: Ron Bonica <[email protected]> Date: Tuesday, 7 January 2020 at 19:07 To: "Pablo Camarillo (pcamaril)" <[email protected]> Cc: SPRING WG <[email protected]> Subject: RE: [spring] SRv6 Network Programming - ICMP Source Address Selection Pablo, Let me try to ask the question another way: 1) Is it generally acceptable for a SID to appear in the source address field of an IPv6 header? 2) Can an exception be made for ICMP messages? I think that the answer to the first question is “no”, because doing so would break ICMP. Think about what would happen if: - Node S sends a packet to Node D with a SID S as its source address. - Node Q is an intermediate node on the path from Node S to Node D. For some reason, Node Q cannot forward the packet. - Node Q sends an ICMP message to Node S. The ICMP destination address is SID S. - The ICMP message arrives at Node A - Node A discards the ICMP message, because the payload is ICMP It might be OK to make an exception for ICMP messages. This is because RFC 4443 forbids sending an ICMP message in response to another ICMP message. However, I am not entirely sure that this is a good idea. One day in the future, some protocol other than ICMP may try send a response to the source address of the ICMP message. Ron Juniper Business Use Only From: Pablo Camarillo (pcamaril) <[email protected]> Sent: Tuesday, January 7, 2020 4:18 AM To: Ron Bonica <[email protected]> Cc: SPRING WG <[email protected]> Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection Ron, It’s good to see agreement on the fact that SRH follows RFC4443 Section 2.2 with respect to how the ICMP Source Address is selected. Can you please point me to the text in draft-ietf-spring-srv6-network-programming that changes the behavior below from RFC4443 Section 2.2? I believe there is no such text. Thanks, Pablo. From: Ron Bonica <[email protected]<mailto:[email protected]>> Date: Saturday, 21 December 2019 at 20:59 To: "Pablo Camarillo (pcamaril)" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [spring] SRv6 Network Programming - ICMP Source Address Selection Pablo, Section 2.2 of RFC 4443 offers the following options: “ (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. “ So, the question boils down to whether you consider a SID to be one of the node’s unicast addresses. If so, the answer is a). If not, the answer is b). So, which is it? Happy Holidays, Ron Juniper Business Use Only From: Pablo Camarillo (pcamaril) <[email protected]<mailto:[email protected]>> Sent: Friday, December 20, 2019 12:30 PM To: Ron Bonica <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection Ron, I guess that draft-ietf-6man-segment-routing-header does not contain any explicit text about it because it is not needed. Instead draft-ietf-6man-segment-routing-header contains a reference to RFC4443 that details in section 2.2 how to select it. There is no text in draft-ietf-spring-srv6-network-programming that changes such behavior. Happy Holidays, Pablo. From: spring <[email protected]<mailto:[email protected]>> on behalf of Ron Bonica <[email protected]<mailto:[email protected]>> Date: Thursday, 19 December 2019 at 14:59 To: "Pablo Camarillo (pcamaril)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection Pablo, Can you provide a specific reference into draft-ietf-6man-segment-routing-header? I can’t find the answer to my question in there. Ron Juniper Business Use Only From: Pablo Camarillo (pcamaril) <[email protected]<mailto:[email protected]>> Sent: Thursday, December 19, 2019 6:47 AM To: Ron Bonica <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: SRv6 Network Programming - ICMP Source Address Selection Ron, This is exactly the same as in the SRH. There is no text in draft-ietf-spring-srv6-network-programming that changes this. Cheers, Pablo. From: Ron Bonica <[email protected]<mailto:[email protected]>> Date: Monday, 9 December 2019 at 23:48 To: "Pablo Camarillo (pcamaril)" <[email protected]<mailto:[email protected]>>, SPRING WG <[email protected]<mailto:[email protected]>>, 6man <[email protected]<mailto:[email protected]>> Subject: RE: SRv6 Network Programming - ICMP Source Address Selection Pablo, Section 2.2 of RFC 4443 offers two options. If you think that a SID is a unicast address, the first option is applicable. If you think that a SID is not a unicast address, the second option is applicable. Which did you choose? Ron Juniper Business Use Only From: Pablo Camarillo (pcamaril) <[email protected]<mailto:[email protected]>> Sent: Monday, December 9, 2019 10:18 AM To: Ron Bonica <[email protected]<mailto:[email protected]>>; SPRING WG <[email protected]<mailto:[email protected]>>; 6man <[email protected]<mailto:[email protected]>> Subject: Re: SRv6 Network Programming - ICMP Source Address Selection Ron, As you pointed out in your email, RFC4443 Section 2.2 is very clear about how to select the source address. draft-ietf-spring-srv6-network-programming does not change this. Thanks, Pablo. From: ipv6 <[email protected]<mailto:[email protected]>> on behalf of Ron Bonica <[email protected]<mailto:[email protected]>> Date: Friday, 6 December 2019 at 17:40 To: SPRING WG <[email protected]<mailto:[email protected]>>, 6man <[email protected]<mailto:[email protected]>> Subject: SRv6 Network Programming - ICMP Source Address Selection Authors, When an SRv6 node sends an ICMP message, how does it select the ICMP message’s source address? Section 2.2 of RFC 4443 offers two options. If you think that a SID is a unicast address, the first option is applicable. If you think that a SID is not a unicast address, the second option is applicable. Ron Juniper Business Use Only Please excuse any typos, sent from my 'smart'phone. Please excuse any typos, sent from my 'smart'phone.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
