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

[Mark Smith <[e-mail]>]

On Tue, 14 Jan 2020, 05:29 Joel M. Halpern, <[e-mail]> 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 <[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://www.ietf.org/mailman/listinfo/spring
> >
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>