Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

[Ron Bonica <[e-mail]>]

Pablo,

Can we disregard Robert's claim, quoted below?

- https://mailarchive.ietf.org/arch/msg/spring/u1AzYFpDe-AhIxXdih2BEIz65Bk

                                                                         Ron


Juniper Business Use Only

-----Original Message-----
From: Pablo Camarillo (pcamaril) <[e-mail]> 
Sent: Tuesday, January 14, 2020 12:43 PM
To: [e-mail]; Ron Bonica <[e-mail]>
Cc: [e-mail]
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Joel,

I think you might be mistaken.

RFC8402: 
	SRv6 SID: an IPv6 address explicitly associated with the segment.

SRH: 
	Segment List[n]: 128 bit IPv6 addresses representing the nth
     	 segment in the Segment List.

NET-PGM:
	   RFC8402 defines an SRv6 Segment Identifier as an IPv6 address
   	explicitly associated with the segment.

Thanks,
Pablo.

-----Original Message-----
From: "Joel M. Halpern" <[e-mail]>
Date: Monday, 13 January 2020 at 19:29
To: "Pablo Camarillo (pcamaril)" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

    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.  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 <[e-mail]>
    > *Date: *Friday, 10 January 2020 at 20:09
    > *To: *"Pablo Camarillo (pcamaril)" <[e-mail]>
    > *Cc: *"[e-mail]" <[e-mail]>
    > *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) <[e-mail]>
    > *Sent:* Friday, January 10, 2020 11:54 AM
    > *To:* Ron Bonica <[e-mail]>
    > *Cc:* [e-mail]
    > *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 <[e-mail] <mailto:[e-mail]>>
    > *Date: *Tuesday, 7 January 2020 at 19:07
    > *To: *"Pablo Camarillo (pcamaril)" <[e-mail] 
    > <mailto:[e-mail]>>
    > *Cc: *SPRING WG <[e-mail] <mailto:[e-mail]>>
    > *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) <[e-mail] 
    > <mailto:[e-mail]>>
    > *Sent:* Tuesday, January 7, 2020 4:18 AM
    > *To:* Ron Bonica <[e-mail] <mailto:[e-mail]>>
    > *Cc:* SPRING WG <[e-mail] <mailto:[e-mail]>>
    > *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 <[e-mail] <mailto:[e-mail]>>
    > *Date: *Saturday, 21 December 2019 at 20:59
    > *To: *"Pablo Camarillo (pcamaril)" <[e-mail] 
    > <mailto:[e-mail]>>
    > *Cc: *"[e-mail] <mailto:[e-mail]>" <[e-mail] 
    > <mailto:[e-mail]>>
    > *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) <[e-mail] 
    > <mailto:[e-mail]>>
    > *Sent:* Friday, December 20, 2019 12:30 PM
    > *To:* Ron Bonica <[e-mail] <mailto:[e-mail]>>
    > *Cc:* [e-mail] <mailto:[e-mail]>
    > *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 <[e-mail] 
    > <mailto:[e-mail]>> on behalf of Ron Bonica 
    > <rbonica=[e-mail] 
    > <mailto:rbonica=[e-mail]>>
    > *Date: *Thursday, 19 December 2019 at 14:59
    > *To: *"Pablo Camarillo (pcamaril)" <[e-mail] 
    > <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" 
    > <[e-mail] <mailto:[e-mail]>>
    > *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) <[e-mail] 
    > <mailto:[e-mail]>>
    > *Sent:* Thursday, December 19, 2019 6:47 AM
    > *To:* Ron Bonica <[e-mail] <mailto:[e-mail]>>; 
    > [e-mail] <mailto:[e-mail]>
    > *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 <[e-mail] <mailto:[e-mail]>>
    > *Date: *Monday, 9 December 2019 at 23:48
    > *To: *"Pablo Camarillo (pcamaril)" <[e-mail] 
    > <mailto:[e-mail]>>, SPRING WG <[e-mail] 
    > <mailto:[e-mail]>>, 6man <[e-mail] <mailto:[e-mail]>>
    > *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) <[e-mail] 
    > <mailto:[e-mail]>>
    > *Sent:* Monday, December 9, 2019 10:18 AM
    > *To:* Ron Bonica <[e-mail] <mailto:[e-mail]>>; 
    > SPRING WG <[e-mail] <mailto:[e-mail]>>; 6man 
    > <[e-mail] <mailto:[e-mail]>>
    > *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 <[e-mail] <mailto:[e-mail]>> on 
    > behalf of Ron Bonica <rbonica=[e-mail] 
    > <mailto:rbonica=[e-mail]>>
    > *Date: *Friday, 6 December 2019 at 17:40
    > *To: *SPRING WG <[e-mail] <mailto:[e-mail]>>, 6man 
    > <[e-mail] <mailto:[e-mail]>>
    > *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
    > [e-mail]
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!XsYfcsn8zylD2GA3gujyjC3w_XX073_GCkqQ8B3M6Fzb6qTPXsJmdRw-gEvAT9Mj$ 
    >