Pablo,
Your point is well-taken. We should remind the reader to abide by *all* RFC
4291 and RFC 8200 validation rules, not just source address validation . I
recommend that you make the following change to Section 4.2:
OLD>
S15. Set the packet's egress adjacency to a member of J
<OLD
NEW>
S15. Set the packet's egress adjacency to a member of J. Then, validate and
transmit the packet. Validation MUST include all rules specified by RFC 4291
and 8200 (e.g., the source address MUST not be multicast or link-local).
<NEW
The following are some strong reasons for this change:
- In the current text, you select the egress adjacency and stop short. You
never say that you are submitting the packet to a forwarding module that
validates the packet as per RFCs 4291 and 8200. In fact, you never say that you
actually forward the packet at all.
- Source validation is particularly important. Failure to enforce the
above-mentioned rules can leave a network open to security vulnerabilities.
- It is likely that some readers of this document are routing experts, but not
IPv6 experts. A reminder might be appreciated by those who are not IPv6 experts.
- A strict reading of Section 4.2 suggest that the END.X function might ignore
RFC 4291 and RFC 8200 validations. Since the document explores the edges
compliance in other places, you probably want to be clear about compliance in
Section 4.2.
Happy Holidays,
Ron
Juniper Business Use Only
-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email protected]>
Sent: Saturday, December 14, 2019 5:01 AM
To: Ron Bonica <[email protected]>; Ron Bonica
<[email protected]>; Darren Dukes (ddukes) <[email protected]>
Cc: SPRING WG <[email protected]>; Bob Hinden <[email protected]>; Mark Smith
<[email protected]>
Subject: Re: [spring] SRv6 Network Programming and Link Local Source Addresses
Ron,
Let's say other RFC defines rules X,Y,Z.
Draft-ietf-spring-srv6-network-programming follows those RFCs and hence those
rules.
You have a concern that no-one else is sharing on rule Y, and you are asking me
to include a reminder saying that Y MUST be followed, but remain silent on X
and Z.
What does this mean for X and Z? Does this mean that someone implementing
draft-ietf-spring-srv6-network-programming can ignore X and Z?
Hence, unless you provide a strong reason why such reminder only for Y is
needed, I keep my position of agreeing with Bob, Darren and Kamran that such
clarification should not be added. Its misleading In my opinion for X and Z.
Please provide me an argument or a reason for it.
Thank you,
Pablo.
-----Original Message-----
From: Ron Bonica <[email protected]>
Date: Wednesday, 11 December 2019 at 21:37
To: "Pablo Camarillo (pcamaril)" <[email protected]>, Ron Bonica
<[email protected]>, "Darren Dukes (ddukes)"
<[email protected]>
Cc: SPRING WG <[email protected]>, Bob Hinden <[email protected]>, Mark Smith
<[email protected]>
Subject: RE: [spring] SRv6 Network Programming and Link Local Source Addresses
Pablo,
I am happy to hear that you would not forward the packet. That is the
correct behavior.
Could we make that point clear in the draft?
Ron
Juniper Business Use Only
-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email protected]>
Sent: Wednesday, December 11, 2019 3:07 PM
To: Ron Bonica <[email protected]>; Ron Bonica
<[email protected]>; Darren Dukes (ddukes) <[email protected]>
Cc: SPRING WG <[email protected]>; Bob Hinden <[email protected]>; Mark
Smith <[email protected]>
Subject: Re: [spring] SRv6 Network Programming and Link Local Source
Addresses
Ron,
Ok. Let me try to be open-minded and understand why you have a concern that
no-one else is sharing:
I guess that your concern is that since we do not have a second FIB lookup,
hence you believe that we would just cross-connect the packet. Is this correct?
The fact that we set the egress adjacency as part of the End.X pseudocode
does not mean that we skip the IPv6 processing, and as part of the IPv6
processing we would not forward such packet.
Thanks,
Pablo.
-----Original Message-----
From: Ron Bonica <[email protected]>
Date: Tuesday, 10 December 2019 at 00:03
To: "Pablo Camarillo (pcamaril)" <[email protected]>, Ron Bonica
<[email protected]>, "Darren Dukes (ddukes)"
<[email protected]>
Cc: SPRING WG <[email protected]>, Bob Hinden <[email protected]>, Mark
Smith <[email protected]>
Subject: RE: [spring] SRv6 Network Programming and Link Local Source
Addresses
Pablo,
Let us agree to disagree.
Chairs,
Please do not close this issue.
Ron
Juniper Business Use Only
-----Original Message-----
From: spring <[email protected]> On Behalf Of Pablo Camarillo
(pcamaril)
Sent: Monday, December 9, 2019 10:16 AM
To: Ron Bonica <[email protected]>; Darren Dukes
(ddukes) <[email protected]>
Cc: SPRING WG <[email protected]>; Bob Hinden <[email protected]>;
Mark Smith <[email protected]>
Subject: Re: [spring] SRv6 Network Programming and Link Local Source
Addresses
Ron,
I agree with Bob, Darren and Kamran that the existing IPv6 processing
rules are followed in Network Programming and do not need to be re-stated.
Cheers,
Pablo.
-----Original Message-----
From: spring <[email protected]> on behalf of Ron Bonica
<[email protected]>
Date: Friday, 6 December 2019 at 17:17
To: "Darren Dukes (ddukes)" <[email protected]>
Cc: SPRING WG <[email protected]>, Bob Hinden <[email protected]>,
Mark Smith <[email protected]>
Subject: Re: [spring] SRv6 Network Programming and Link Local Source
Addresses
Darren,
If the draft adhered strictly to RFC 4291 and RFC 8200 in all other
respects, I would agree with you and Bob. However, it doesn't.
As it stands, the reader is left to guess when the draft adheres to
previous specifications, but doesn't say so explicitly, and when it is taking
liberties with previous specifications.
Ron
Juniper Business Use Only
-----Original Message-----
From: Darren Dukes (ddukes) <[email protected]>
Sent: Friday, December 6, 2019 10:53 AM
To: Ron Bonica <[email protected]>
Cc: Bob Hinden <[email protected]>; SPRING WG <[email protected]>;
Mark Smith <[email protected]>
Subject: Re: [spring] SRv6 Network Programming and Link Local
Source Addresses
Hi Ron, I agree with Bob here.
Section 4.2 pseudocode simply says an implementation would use a
predetermined egress adjacency instead of performing a FIB lookup to find one.
It specifies the SID processing, not the entire IPv6 data path.
It has no text that would indicate RFC4291 text on link-local
addresses and routers would not apply.
As a side note, every routing header currently defined (even those
now deprecated) do not re-state the RFC4291 text.
Thanks,
Darren
> On Dec 2, 2019, at 10:58 AM, Ron Bonica
<[email protected]> wrote:
>
> Bob,
>
> Before we debate presentation too much, we should let Pablo
answer the original question. Will the packet be dropped or forwarded?
>
> If the packet will be dropped, how is the reader of Section 4.2
to know this? Normally, pseudocode is taken literally, and the pseudocode in
Section 4.2 suggests that the packet will be forwarded.
>
> One way to wiggle out of this problem is to include a sentence at
the beginning of Section 4 saying, "When the following pseudocode contradicts
RFC 4291 or 8200, RFCs 4291 and 8200 take precedence.
>
>
> Ron
>
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Bob Hinden <[email protected]>
> Sent: Monday, December 2, 2019 10:47 AM
> To: Ron Bonica <[email protected]>
> Cc: Bob Hinden <[email protected]>; Mark Smith
> <[email protected]>; SPRING WG <[email protected]>
> Subject: Re: [spring] SRv6 Network Programming and Link Local
Source
> Addresses
>
> Ron,
>
>> On Dec 2, 2019, at 7:36 AM, Ron Bonica <[email protected]>
wrote:
>>
>> Bob,
>>
>> Take a look at Section 4.2. The pseudocode is pretty specific.
>
> Please explain. I don’t see that.
>
> Thanks,
> Bob
>
>
>>
>> Ron
>>
>>
>>
>> Juniper Business Use Only
>>
>> -----Original Message-----
>> From: Bob Hinden <[email protected]>
>> Sent: Sunday, December 1, 2019 5:56 PM
>> To: Ron Bonica <[email protected]>
>> Cc: Bob Hinden <[email protected]>; Mark Smith
>> <[email protected]>; SPRING WG <[email protected]>
>> Subject: Re: [spring] SRv6 Network Programming and Link Local
Source
>> Addresses
>>
>> Ron,
>>
>>> On Dec 1, 2019, at 2:47 PM, Ron Bonica <[email protected]>
wrote:
>>>
>>> Mark, Bob,
>>>
>>> Yes, I agree that routers should not forward packets with link
local source addresses.
>>
>> or Destination addresses.
>>
>>>
>>> Pablo,
>>>
>>> Maybe we should update section 4.2 of the network programming
draft to reflect this?
>>
>> I was thinking that unless network programming has text that
might cause one to think it overrides the defined behavior from rfc4291 for
link-local addresses, I am not sure it has to be mentioned.
>>
>> Bob
>>
>>
>>>
>>>
Ron
>>>
>>>
>>> From: Mark Smith <[email protected]>
>>> Sent: Sunday, December 1, 2019 5:31 PM
>>> To: Bob Hinden <[email protected]>
>>> Cc: Ron Bonica <[email protected]>; SPRING WG
<[email protected]>
>>> Subject: Re: [spring] SRv6 Network Programming and Link Local
Source
>>> Addresses
>>>
>>>
>>>
>>> On Mon, 2 Dec 2019, 08:35 Bob Hinden, <[email protected]>
wrote:
>>> Ron,
>>>
>>>> On Nov 30, 2019, at 12:36 PM, Ron Bonica
<[email protected]> wrote:
>>>>
>>>> Pablo,
>>>>
>>>>
>>>>
>>>> Consider the packet (SA,DA) (S3, S2, S1; SL) where:
>>>>
>>>>
>>>>
>>>> • SA is link-local (fe80)
>>>> • DA, S3, S2, and S1 are all END.X
>>>>
>>>>
>>>> Section 4.2 suggests that this packet will be delivered over
multiple hops to its destination, regardless of its link-local source address.
>>>
>>> I would think that RFC2460 Section 2.5.6. "Link-Local IPv6
Unicast Addresses” covers this:
>>>
>>> Link-Local addresses are for use on a single link. Link-Local
>>> addresses have the following format:
>>>
>>> | 10 |
>>> | bits | 54 bits | 64 bits
|
>>>
+----------+-------------------------+----------------------------+
>>> |1111111010| 0 | interface ID
|
>>>
+----------+-------------------------+----------------------------+
>>>
>>> Link-Local addresses are designed to be used for addressing on
a
>>> single link for purposes such as automatic address
configuration,
>>> neighbor discovery, or when no routers are present.
>>>
>>> Routers must not forward any packets with Link-Local source or
>>> destination addresses to other links.
>>>
>>> I think that's RFC4291.
>>>
>>> RFC4007, "IPv6 Scoped Address Architecture" does too, more
generally and probably more formally, in particular section 9, "Forwarding".
>>>
>>> Regards,
>>> Mark.
>>>
>>>
>>>
>>> Bob
>>>
>>>
>>>>
>>>>
>>>>
>>>> Is this the case?
>>>>
>>>>
>>>>
>>>> Ron
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Juniper Business Use Only
>>>> _______________________________________________
>>>> spring mailing list
>>>> [email protected]
>>>>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/s
>>>>
pring__;!8WoA6RjC81c!X0Mi1EMDcUpqGxHLkmQkX30EHTgzVWkxOQTTSCO1ZK60Y1
>>>> fsLwpCkacVdsltFrrl$
>>>
>>> _______________________________________________
>>> spring mailing list
>>> [email protected]
>>>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
>>>
ring__;!8WoA6RjC81c!X0Mi1EMDcUpqGxHLkmQkX30EHTgzVWkxOQTTSCO1ZK60Y1fs
>>> LwpCkacVdsltFrrl$
>>>
>>> Juniper Business Use Only
> _______________________________________________
> spring mailing list
> [email protected]
>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
>
ng__;!8WoA6RjC81c!X0Mi1EMDcUpqGxHLkmQkX30EHTgzVWkxOQTTSCO1ZK60Y1fsLwpCkacVdsltFrrl$
_______________________________________________
spring mailing list
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S9ht1iKevwXKxhNLJwPAOviqxEttD_Ij3orL76Tjf6j0zxxgxMKwhMJ8iuT8hyc0$
_______________________________________________
spring mailing list
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S9ht1iKevwXKxhNLJwPAOviqxEttD_Ij3orL76Tjf6j0zxxgxMKwhMJ8iuT8hyc0$
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
