Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 1 May 2017 07:40:42 +0000

Naiming,
Lots of thanks for a prompt response.

Unfortunately, I do not think that your response addresses your concern.

RFC 5309 explicitly mentions “ARP implementation (which checks that the subnet of the source address of the ARP request matches the local interface address)”. Actually, ARP implementations frequently check that the source IP address in an ARP request is in the subnet of the local interface address. E.g., AFAIK, this is the standard behavior of the Linux ARP implementation. To the best of my understanding this was the check that RFC 5309 implied, because there is no way the subnet of the source address of the ARP request could be known.

If such check is applied, then the scenario I’ve described becomes valid. I can add that I have observed several implementations that experience the described behavior (i.e., blackholing of unicast IP traffic that OSPF tries to route via such a link). Some other implementations seem to behave better.

Regards,
Sasha

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: Naiming Shen (naiming) [mailto:[email-masked]]
Sent: Monday, May 01, 2017 5:34 AM
To: Alexander Vainshtein <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; RFC Errata System <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Alvaro Retana (aretana) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander,

If you are saying the local LAN interface is explicitly configured with
a different subnet IP address then the peer, I don’t think there is any
problem with the ARP, and also with this RFC. Since ARP will always
reply to answer its own IP addresses on the interface upon request.

This RFC is only saying, if it’s p2p-over-lan over an unnumbered IP address,
and this LAN interface needs to proxy-ARP the IP address it binds to.
If the ARP already replies since you have an IP address, and our
p2p-over-LAN intf also uses this IP address, nothing is broken.

thanks.
- Naiming

On Apr 30, 2017, at 8:50 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:

Les,
Lots of thanks for a prompt response.

As I see it, the difference between the P2P and LAN modes is essential for OSPF:
- If an OSPF interface is a LAN (broadcast) interface, there is a check of the same subnet for received Hello packets. If the received Hello packets do not pass this check, they are discarded and an error is reported via SNMP.
- However, if an OSPF interface is a P2P interface, then the subnet check on the Hello packets is bypassed  by design as defined in Section 10.5 of RFC 2328:

                     The generic input processing of OSPF packets will
        have checked the validity of the IP header and the OSPF packet
        header.  Next, the values of the Network Mask, HelloInterval,
        and RouterDeadInterval fields in the received Hello packet must
        be checked against the values configured for the receiving
        interface.  Any mismatch causes processing to stop and the
        packet to be dropped.  In other words, the above fields are
        really describing the attached network's configuration. However,
        there is one exception to the above rule: on point-to-point
        networks and on virtual links, the Network Mask in the received
        Hello Packet should be ignored.

I.e., having different subnets on two ends of a PPP link would not cause any problems for OSPF - the adjacency would be successfully recognized, it would progress to its FULL state, and unicast traffic would cross such a link without any problem.

But if we have a P2P-over-LAN link (which is the case for RFC 5309), the result would be quite different - unless the ARP implementations go beyond what 5309 says and relax the check for all such links, be they numbered or unnumbered.

Do I miss something substantial here?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

I am not speaking for the RFC authors, but regarding your point:

> o          Are assigned with IP addresses and subnet masks yielding different
> subnets

I fail to see why this issue is unique to (or associated with) running in P2P mode.

The unnumbered case is specifically mentioned because in such a case it can be expected that the next hop address will be a loopback address and therefore there will be no common subnet.
But in the numbered case whether you have one neighbor in P2P mode or many neighbors in multi-access mode the msimatched subnet issue is the same. Therefore I see no reason why these RFCs should discuss it.

???

   Les

> -----Original Message-----
> From: Isis-wg [mailto:[email-masked]] On Behalf Of RFC
> Errata System
> Sent: Sunday, April 30, 2017 1:16 AM
> To: Naiming Shen (naiming); [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana);
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> rfc-editor@rfc- editor.org<http://webdefence.global.blackspider.com/urlwrap/?q=AXicE3RmiL7GwDDlCANDUU6lgUmSXnFRmV5uYmZOcn5eSVF-jl5yfi5DmYmhUUREcLmBkaGRuQmDY05qRWJeSmqRXlhiZl5xRklqZp5DanJmSWpOKlh9RklJgZW-fmpKZkl-kV5-UToDA0PFQQYGAOFQJGs&Z>
> Subject: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)
>
> The following errata report has been submitted for RFC5309,
> "Point-to-Point Operation over LAN in Link State Routing Protocols".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5309&eid=5007
>
> --------------------------------------
> Type: Technical
> Reported by: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
>
> Section: 4.3
>
> Original Text
> -------------
> For the ARP implementation (which checks that the subnet of the source
> address of the ARP request matches the local interface address), this
> check needs to be relaxed for the unnumbered p2p-over-lan circuits.
>
> Corrected Text
> --------------
> For the ARP implementation (which checks that the subnet of the source
> address of the ARP request matches the local interface address), this
> check needs to be relaxed for the p2p-over-lan circuits (both numbered
> and unnumbered).
>
> Notes
> -----
> Consider the following situation:
> 1.         Two routers, R1 and R2, are connected by a physical P2P  Ethernet
> link
> 2.         OSPFv2 is enabled on the interfaces representing the endpoints of
> this link.
> 3.      From the OSPF POV these interfaces:
> o          Are configured as P2P
> o          Belong to the same area
> o          Are assigned with IP addresses and subnet masks yielding different
> subnets
> 4.    ARP check mentioned in the problematic text is not relaxed.
>
> Under this conditions:
> -Both R1 and R2 will accept Hello messages sent by the other router
> (becase it ignores subnet in Hello messages received via P2P
> interfaces)
> - Adjacency between R1 and R2 will progress to FULL state (because all
> OSPFv2 messages will be sent with AllSPFRouters multicast IPv4
> address)
> - Unicast traffic sent by R1 to R2 (and vice versa) will be blackholed
> because ARP will not resolve addresses assigned to the corresponding interfaces.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or rejected.
> When a decision is reached, the verifying party can log in to change
> the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5309 (draft-ietf-isis-igp-p2p-over-lan-06)
> --------------------------------------
> Title               : Point-to-Point Operation over LAN in Link State Routing
> Protocols
> Publication Date    : October 2008
> Author(s)           : N. Shen, Ed., A. Zinin, Ed.
> Category            : INFORMATIONAL
> Source              : IS-IS for IP Internets
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> Isis-wg mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/isis-wg

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 1 May 2017 07:50:03 +0000

Les,
Lots of thanks for the clarification.
I fully agree with you that configuring a pair of interfaces across a P2P link with IP addresses from different subnets should not be encouraged even if these interfaces operate as P2P from the POV of the routing protocol.

The problem is that the scenario I've described is quite real, and, AFAIK,  no standard explicitly says that it is not supported.

I also do not fully  understand  your usage of plural ("these RFCs") - I have been only asking about a correction in a single RFC -5309.

I see several ways to resolve the problem:

1.       Recognize the erratum and hold it for the update of 5309

2.       Explicitly state that numbered P2P-over-LAN interfaces must still configure the terminating interfaces of the LAN link with IPv4 addresses from the same subnet (could be another sort of update for 5309).

What would you suggest?

Regard, and lots of thanks in advance,
Sasha

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 10:44 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; RFC Errata System <[email-masked]>; Naiming Shen (naiming) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Alvaro Retana (aretana) <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Sasha -

The language you are asking to be changed is in regards to ARP. I am saying allowing an adjacency to be formed on a numbered LAN with mismatched subnets is neither introduced nor altered by these RFCs .
What is introduced is the possibility of operating on an unnumbered LAN - which is why the RFCs speak to that.

If you want to ask that protocol base specifications discuss ARP issues when mismatched subnets are allowed (which I am NOT encouraging you to do) then you will be directing your comments at the correct documents.
Asking that of these RFCs is inappropriate.

   Les

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 8:51 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]<mailto:[email-masked]>; RFC Errata System; Naiming Shen (naiming); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Les,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

> rfc-editor@rfc- editor.org

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 1 May 2017 15:04:28 +0000

Sasha -

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, May 01, 2017 12:50 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; RFC Errata System; Naiming Shen (naiming); [email-masked]; [email-masked]; [email-masked]; Alvaro Retana (aretana); [email-masked]; [email-masked]
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Les,

[Les:] This is not what I said. I said:

"allowing an adjacency to be formed on a numbered LAN with mismatched subnets is neither introduced nor altered by these RFCs ."

[Les:] Yes - it is real. But as RFC 5309 did not introduce or alter this behavior it is not the appropriate place to comment on it.

[Les:] My mistake - I was thinking there was a separate RFC for OSPF/IS-IS - but RFC 5309 cobvers both.

What would you suggest?

[Les:] I suggest we do no nothing.

   Les

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 10:44 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Sasha -

   Les

Les,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 4 May 2017 10:03:34 +0000

Les,
Lots of thanks for a detailed response. It seems that we are now in sync regarding the problem.

Doing nothing with this problem is of course one of the possible options:).
I wonder how should we reach consensus regarding its handling.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Monday, May 01, 2017 6:04 PM

Sasha -

Les,

What would you suggest?

   Les

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha -

   Les

Les,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 4 May 2017 14:19:33 +0000

+ospf-wg list

While very implementation specific, P2P over LAN isn’t described anywhere other than RFC 5309. The point Sasha is making is that OSPF doesn’t enforce subnet match checking on P2P links (which is true) and the ARP must do the same. Hence, I would agree with the errata.

Original Text
-------------
For the ARP implementation (which checks that the subnet of the source address of the ARP request matches the local interface address), this check needs to be relaxed for the unnumbered p2p-over-lan circuits.

Corrected Text
--------------
For the ARP implementation (which checks that the subnet of the source address of the ARP request matches the local interface address), this check needs to be relaxed for the p2p-over-lan circuits (both numbered and unnumbered).

Let’s go forward with this and not spend any more time debating it.

Thanks,
Acee

From: Isis-wg <[email-masked]<mailto:[email-masked]>> on behalf of Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 4, 2017 at 6:03 AM
To: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Deborah Brungard <[email-masked]<mailto:[email-masked]>>, Christian Hopps <[email-masked]<mailto:[email-masked]>>, RFC Errata System <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Les,

Doing nothing with this problem is of course one of the possible options☺.
I wonder how should we reach consensus regarding its handling.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha -

Les,

“allowing an adjacency to be formed on a numbered LAN with mismatched subnets is neither introduced nor altered by these RFCs .”

The problem is that the scenario I’ve described is quite real, and, AFAIK,  no standard explicitly says that it is not supported.

[Les:] Yes – it is real. But as RFC 5309 did not introduce or alter this behavior it is not the appropriate place to comment on it.

I also do not fully  understand  your usage of plural (“these RFCs”) – I have been only asking about a correction in a single RFC -5309.

[Les:] My mistake – I was thinking there was a separate RFC for OSPF/IS-IS – but RFC 5309 cobvers both.

What would you suggest?

   Les

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha –

The language you are asking to be changed is in regards to ARP. I am saying allowing an adjacency to be formed on a numbered LAN with mismatched subnets is neither introduced nor altered by these RFCs .
What is introduced is the possibility of operating on an unnumbered LAN – which is why the RFCs speak to that.

   Les

Les,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 May 2017 15:07:45 +0000

Acee –

Any ARP issues which might occur for numbered interfaces where neighbors do not have matching subnets will occur independent of P2P mode. I therefore see no reason why RFC 5309 should address this issue.

If you feel this needs to be addressed (I don’t – but YMMV) then I think errata should be against RFC 2328.

Note that in the case of IS-IS we have RFC 3787 Section 10 – which concludes by saying:

“…The  network administrator should ensure that there is a common IP subnet
   assigned to links with numbered interfaces, and that all routers on
   each link have a IP Interface Addresses belonging to the assigned
   subnet.”

   Les

From: Acee Lindem (acee)
Sent: Thursday, May 04, 2017 7:20 AM
To: Alexander Vainshtein; Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; RFC Errata System; OSPF WG List
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

+ospf-wg list

Original Text
-------------

Corrected Text
--------------

Thanks,
Acee

Les,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha -

Les,

What would you suggest?

   Les

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha –

   Les

Les,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 4 May 2017 15:20:09 +0000

Hi Les,

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 4, 2017 at 11:07 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Deborah Brungard <[email-masked]<mailto:[email-masked]>>, Christian Hopps <[email-masked]<mailto:[email-masked]>>, RFC Errata System <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Acee –

You may not be aware that subnet checking on numbered P2P links (which is enforced by many router implementations) is not standard. In fact, BSD implementations (which were very popular in the pre-Linux era), model a P2P link as simply a connection between two endpoints as opposed to a subnet.

This statement in RFC 5309 is respect to ARP – not OSPF. After several decades, we’re certainly not going to change OSPF to enforce subnet checking on P2P links.

OSPF supports both models of P2P link. OSPF has been widely deployed on hosts as well as routers. See this excerpt from RFC 2328 and note Option 1:

            12.4.1.1.  Describing point-to-point interfaces

                For point-to-point interfaces, one or more link
                descriptions are added to the router-LSA as follows:

                o   If the neighboring router is fully adjacent, add a
                    Type 1 link (point-to-point). The Link ID should be
                    set to the Router ID of the neighboring router. For
                    numbered point-to-point networks, the Link Data
                    should specify the IP interface address. For
                    unnumbered point-to-point networks, the Link Data
                    field should specify the interface's MIB-II [Ref8]
                    ifIndex value. The cost should be set to the output
                    cost of the point-to-point interface.

                o   In addition, as long as the state of the interface
                    is "Point-to-Point" (and regardless of the
                    neighboring router state), a Type 3 link (stub
                    network) should be added. There are two forms that
                    this stub link can take:

                    Option 1
                        Assuming that the neighboring router's IP
                        address is known, set the Link ID of the Type 3
                        link to the neighbor's IP address, the Link Data
                        to the mask 0xffffffff (indicating a host
                        route), and the cost to the interface's
                        configured output cost.[15]

                    Option 2
                        If a subnet has been assigned to the point-to-
                        point link, set the Link ID of the Type 3 link
                        to the subnet's IP address, the Link Data to the
                        subnet's mask, and the cost to the interface's
                        configured output cost.[16]

Thanks,
Acee

   Les

From: Acee Lindem (acee)
Sent: Thursday, May 04, 2017 7:20 AM
To: Alexander Vainshtein; Les Ginsberg (ginsberg)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; RFC Errata System; OSPF WG List
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

+ospf-wg list

Original Text
-------------

Corrected Text
--------------

Thanks,
Acee

Les,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha -

Les,

What would you suggest?

   Les

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha –

   Les

Les,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 May 2017 15:29:55 +0000

Acee -

From: Acee Lindem (acee)
Sent: Thursday, May 04, 2017 8:20 AM
To: Les Ginsberg (ginsberg); Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; RFC Errata System; OSPF WG List
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Hi Les,

Acee –

[Les:] I am well aware. I am also aware that even on LANs some implementations enforce matching subnet checking and some don’t. Please read the previously mention RFC 3787 Section 10.

[Les:] I never suggested that (and I don’t think Sasha did either). The errata  is suggesting the following new text:

“For the ARP implementation (which checks that the subnet of the source address of the ARP request matches the local interface address), this check needs to be relaxed for the p2p-over-lan circuits (both numbered and unnumbered).”

I am pointing out that this issue is not specific to P2P operation on a LAN.
Naiming has also pointed out that in P2P mode you are less likely to have problems because ARP will always respond to requests for the local address. If there is going to be a problem it is more likely to occur in multi-access mode when an ARP request for a non-local address might be received.

   Les

                    this stub link can take:

                    Option 1

                    Option 2

Thanks,
Acee

   Les

From: Acee Lindem (acee)

+ospf-wg list

Original Text
-------------

Corrected Text
--------------

Thanks,
Acee

Les,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha -

Les,

What would you suggest?

   Les

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha –

   Les

Les,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 4 May 2017 15:31:34 +0000

Les,
ARP issues will not occur between a pair of LAN (not P2P) interfaces with mismatched subnets running OSPF, because the Hello packets received by one of the interfaces would be rejected claiming wrong subnet as the reason.
But this check in OSPF is disabled for P2P interfaces (i.e., for interfaces that are P2P from the OSPF POV).

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, May 04, 2017 6:08 PM
To: Acee Lindem (acee) <[email-masked]>; Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; RFC Errata System <[email-masked]>; OSPF WG List <[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Acee –

   Les

From: Acee Lindem (acee)

+ospf-wg list

Original Text
-------------

Corrected Text
--------------

Thanks,
Acee

Les,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha -

Les,

What would you suggest?

   Les

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha –

   Les

Les,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 4 May 2017 15:36:34 +0000

Les,
RFC 3787 is about IS-IS (at least this is what its title says). And Section 10 you mention explicitly refers to RFC 1195 (i.e., IS-IS).

In the case of OSPFv2 IP addressing definitely affects forming the adjacencies for LAN interfaces.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Thursday, May 04, 2017 6:30 PM

Acee -

From: Acee Lindem (acee)

Hi Les,

Acee –

   Les

                    this stub link can take:

                    Option 1

                    Option 2

Thanks,
Acee

   Les

From: Acee Lindem (acee)

+ospf-wg list

Original Text
-------------

Corrected Text
--------------

Thanks,
Acee

Les,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha -

Les,

What would you suggest?

   Les

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha –

   Les

Les,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 4 May 2017 15:57:27 +0000

Les,

Date: Thursday, May 4, 2017 at 11:29 AM

Acee -

From: Acee Lindem (acee)

Hi Les,

Acee –

This only applies to IS-IS. The recommendations do not apply to OSPF.

I’m confused by this argument. We’re only talking about P2P here. Nobody has suggested to relax the matching subnet restriction on multi-access networks.

Thanks,
Acee

   Les

                    this stub link can take:

                    Option 1

                    Option 2

Thanks,
Acee

   Les

From: Acee Lindem (acee)

+ospf-wg list

Original Text
-------------

Corrected Text
--------------

Thanks,
Acee

Les,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha -

Les,

What would you suggest?

   Les

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha –

   Les

Les,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 5 May 2017 05:43:48 +0000

Sasha,

Thanks for the comments.

In OS implementations, in particular linux, there are various releases and
configure options, so it varies quite a bit for ARP. This pointer shows how to change
the ARP behavior on linux:

http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP

For example, the variable ‘arp_ignore’, has the code sample in ‘arp.c’:
http://elixir.free-electrons.com/linux/latest/source/net/ipv4/arp.c

static int arp_ignore<http://elixir.free-electrons.com/linux/latest/ident/arp_ignore>(struct in_device<http://elixir.free-electrons.com/linux/latest/ident/in_device> *in_dev, __be32<http://elixir.free-electrons.com/linux/latest/ident/__be32> sip<http://elixir.free-electrons.com/linux/latest/ident/sip>, __be32<http://elixir.free-electrons.com/linux/latest/ident/__be32> tip)
{
        struct net *net = dev_net<http://elixir.free-electrons.com/linux/latest/ident/dev_net>(in_dev->dev);
        int scope<http://elixir.free-electrons.com/linux/latest/ident/scope>;

        switch (IN_DEV_ARP_IGNORE<http://elixir.free-electrons.com/linux/latest/ident/IN_DEV_ARP_IGNORE>(in_dev)) {
        case 0: /* Reply, the tip is already validated */
                return 0;
        case 1: /* Reply only if tip is configured on the incoming interface */
                sip<http://elixir.free-electrons.com/linux/latest/ident/sip> = 0;
                scope<http://elixir.free-electrons.com/linux/latest/ident/scope> = RT_SCOPE_HOST<http://elixir.free-electrons.com/linux/latest/ident/RT_SCOPE_HOST>;
                break;
        case 2: /*
                 * Reply only if tip is configured on the incoming interface
                 * and is in same subnet as sip
                 */
                scope<http://elixir.free-electrons.com/linux/latest/ident/scope> = RT_SCOPE_HOST<http://elixir.free-electrons.com/linux/latest/ident/RT_SCOPE_HOST>;
                break;

I have two linux boxes with ubuntu 16.04 connected on an ethernet
and with two different subnet:
lenovo (enp3s0 with IP 192.168.1.35/24) <—> vaio (enp2s8 with IP 192.168.2.100/24)

on vaio: I run an arping to request ARP resolution of 192.168.1.35:
vaio:~$ sudo arping 192.168.1.35 -i enp2s8
60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=0 time=6.538 msec
60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=1 time=1.464 msec
60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=2 time=8.418 msec

I made sure on lenovo as described arp_announce is ‘2’, and arp_ignore is ‘0’:
root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# echo 2 > arp_announce
root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# cat arp_ignore

Run tcpdump on lenovo interface enp3s0 to get ARP packets:
root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# tcpdump -i enp3s0 arp -vv

22:14:01.774491 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.35 tell 192.168.2.100, length 46
22:14:01.774511 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.35 is-at ec:a8:6b:c0:82:23 (oui Unknown), length 28
22:14:02.775522 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.35 tell 192.168.2.100, length 46
22:14:02.775541 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.35 is-at ec:a8:6b:c0:82:23 (oui Unknown), length 28

Ok, so what I’m getting at is that, if you know the system needs to run
numbered and mismatched IP addresses over the same cable, then
regardless of p2p-over-lan or other applications, you probably need to
adjust the local ARP behavior to match what is expected on the OS.

I agree that RFC 5309 does mention the matching IP subnet, and probably
should refer to unnumbered is the most useful use case.

Best Regards,
- Naiming

On May 1, 2017, at 12:40 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:

Naiming,

Regards,
Sasha

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; RFC Errata System <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Alexander,

thanks.
- Naiming

Les,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 5 May 2017 16:19:26 +0000

I don’t know how many implementations actually check the subnet as specified in RFC 1027. I looked at our Nexus software implementations and the only validation done on the source address is that it is not a broadcast address, loopback address, or address in the 0/8 subnet. Additionally, I just looked at the reference implementation in “TCP/IP Illustrated, Volume 2” by Wright and Stevens and the source address subnet is not checked against the destination address.

Thanks,
Acee

From: Isis-wg <[email-masked]<mailto:[email-masked]>> on behalf of "Naiming Shen (naiming)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 5, 2017 at 1:43 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Deborah Brungard <[email-masked]<mailto:[email-masked]>>, Christian Hopps <[email-masked]<mailto:[email-masked]>>, RFC Errata System <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Sasha,

Thanks for the comments.

Best Regards,
- Naiming

Naiming,

Regards,
Sasha

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Alexander,

thanks.
- Naiming

Les,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 7 May 2017 05:35:13 +0000

Naiming,
Lots of thanks for a very detailed response.

I fully agree with you that reasonable ARP implementations (including Linux) provide for enabling or disabling the check of the source IP address.
I also agree that disabling this check on unnumbered P2P-over-LAN interfaces is the most useful use case when this check must be disabled.

I also agree that the if a pair of connected interfaces are configured with IP addresses from mismatched subnets, traffic would not pass unless ARP check is relaxed for both LAN and P2P interfaces. My point is that, in the case of OSPF, if the interfaces were not configured as P2P, an OSPF adjacency would not be formed. Therefore the link would not be part of the network graph and not taken into account in the OSPF routes computation.

But if these interfaces are configured as P2P for OSPF, an adjacency is formed and it reaches its FULL state. The result is blackholing, and RFC 5309 neither instructs the operators to avoid such configuration nor requires from the implementations to relax the ARP check.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Friday, May 05, 2017 8:44 AM

Sasha,

Thanks for the comments.

{

                                         return 0;

                                         break;

                    case 2:          /*

                                          */

                                         break;

Best Regards,
- Naiming

Naiming,

Regards,
Sasha

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Alexander,

thanks.
- Naiming

Les,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les