On Tue, 14 Jan 2020, 05:29 Joel M. Halpern, <[email protected]> wrote:
> Let me try asking the question a different way. (I hope I understand > Ron;s question.) > > RFC 4443 clearly allows the ICMP source to be the destination address of > the offending packet. You seem to be saying that sometimes that is okay > for SRH / network programming. > > At the same time, the SRH document and the network programming document > are both quite clear that SRv6 SIDs are not IPv6 addresses. They are > other kinds of things that can be prefix routed. > If SRv6 SIDs are NOT IPv6 addresses, then there would seem to be a > problem with putting them in the source address field of an ICMP > message. I'd say if SRv6 SIDs are stated not to be IPv6 addresses, then I think there is a problem with using their values anywhere with and in the IPv6 protocol, including packets' DA fields, unless there is a translation function between SRv6 SIDs and IPv6 addresses. The translation function might be nothing more than a simple copy of the 128 bit SID value into the place where it will be used in IPv6, and I understand this would be the motivation for having 128 bit SIDs in SRv6 and 20 bit SIDs in SR-MPLS. However that then means SID values always have to comply with IPv6 address requirements and formats, regardless of SR context. Otherwise, the translation function needs to be a transform between SRv6 SIDs and IPv6 addresses. There is no document that describes or allows anything other > than an IPv6 address as the source address of an IPv6 ICMP. > > It seems like it ought to be possible to clarify this with some text. > It does seem that something ought to be said. > > Yours, > Joel > > On 1/13/2020 12:30 PM, Pablo Camarillo (pcamaril) wrote: > > Ron, > > > > You cannot pre-select or enforce one of the two options you refer to > below. > > > > The ICMP behaviors/considerations for SRv6 NET-PGM are the same as in > > the SRH. > > > > It boils down to: when you generate an ICMP Parameter Problem Message > > you follow the logic described in RFC4443 section 2.2 to choose the > > source address of the packet. > > > > RFC4443 offers two options A and B. > > > > In your implementation you need to develop both options and depending on > > the type of address you will choose either A or B. It is not possible to > > create an implementation shortcut and pre-select/enforce only one of > them. > > > > Can you please point me to the text in > > draft-ietf-spring-srv6-network-programming that suggests that the ICMP > > considerations are changed with respect to the SRH? I believe there is > none. > > > > Thank you, > > > > Pablo. > > > > *From: *Ron Bonica <[email protected]> > > *Date: *Friday, 10 January 2020 at 20:09 > > *To: *"Pablo Camarillo (pcamaril)" <[email protected]> > > *Cc: *"[email protected]" <[email protected]> > > *Subject: *RE: [spring] SRv6 Network Programming - ICMP Source Address > > Selection > > > > Pablo, > > > > So, in Section 4.1, Line S03, an SRv6 node sends an ICMP Parameter > > Problem Message. What is the source address in that message? > > > > Is it the destination address of the offending packet (i.e., A SID)? Or > > is in the address of an interface on the SRv6 node? > > > > > > Ron > > > > Juniper Business Use Only > > > > *From:*Pablo Camarillo (pcamaril) <[email protected]> > > *Sent:* Friday, January 10, 2020 11:54 AM > > *To:* Ron Bonica <[email protected]> > > *Cc:* [email protected] > > *Subject:* Re: [spring] SRv6 Network Programming - ICMP Source Address > > Selection > > > > 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] <mailto:[email protected]>> > > *Date: *Tuesday, 7 January 2020 at 19:07 > > *To: *"Pablo Camarillo (pcamaril)" <[email protected] > > <mailto:[email protected]>> > > *Cc: *SPRING WG <[email protected] <mailto:[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] > > <mailto:[email protected]>> > > *Sent:* Tuesday, January 7, 2020 4:18 AM > > *To:* Ron Bonica <[email protected] <mailto:[email protected]>> > > *Cc:* SPRING WG <[email protected] <mailto:[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. > > > > Please excuse any typos, sent from my 'smart'phone. > > > > > > _______________________________________________ > > spring mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
