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

From: Alia Atlas <[email-masked]>
Date: Tue, 13 Jun 2017 17:18:03 -0400

Chris, Hannes, Les, Sasha,

Is there a conclusion about this Errata report?

>From the discussion, it sounds like there is a problem and the argument is
about
what layer it should be handled by.  Perhaps, instead of normative text, it
could be
a note?

Regards,
Alia

On Sun, May 7, 2017 at 1:35 AM, Alexander Vainshtein <
[email-masked]> wrote:

> 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 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> Email:   [email-masked]
>
>
>
> *From:* Naiming Shen (naiming) [mailto:[email-masked]]
> *Sent:* Friday, May 05, 2017 8:44 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)
>
>
>
>
>
> 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]> wrote:
>
>
>
> 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 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> Email:   [email-masked]
>
>
>
> *From:* Naiming Shen (naiming) [mailto:[email-masked]
> <[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]> 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 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> Email:   [email-masked]
>
>
>
>
>
> -----Original Message-----
> From: Les Ginsberg (ginsberg) [mailto:[email-masked]
> <[email-masked]>]
> Sent: Sunday, April 30, 2017 5:19 PM
> To: RFC Errata System <[email-masked]>; Naiming Shen (naiming)
> <[email-masked]>;[email-masked]; [email-masked];
> [email-masked]; Alvaro Retana (aretana) <[email-masked]>; chopps@
> chopps.org; [email-masked]
> Cc: Alexander Vainshtein <[email-masked]>;
> [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]
> <[email-masked]>] On Behalf Of RFC
>
> > Errata System
>
> > Sent: Sunday, April 30, 2017 1:16 AM
>
> > To: Naiming Shen (naiming); [email-masked];
>
> > [email-masked]; [email-masked]; Alvaro Retana (aretana);
>
> > [email-masked]; [email-masked]
>
> > Cc: [email-masked]; [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]>
>
> >
>
> > 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]
>
> > 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.
> ____________________________________________________________
> _______________
>
>
>
> ____________________________________________________________
> _______________
>
> 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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 14 Jun 2017 01:57:46 +0000

Alia  –

If it were up to me I would NOT address the Errata. As the lengthy discussion on this thread has covered:

1)RFC 5309 did not introduce any new issue here – if anything needed to be done it should not be specified in RFC 5309

2)There isn’t a substantive issue since ARP behavior has a plethora of varieties/knobs/implementations

3)For IS-IS RFC 3787 Section 10 discusses the matching subnet issue in detail – I do not see what more needs to be said.

But I think RFC 5309 authors should weigh in as it is their RFC Sasha wants revised.
Naiming and Acee have commented and I read their remarks as supporting my recommendation.

   Les

From: Alia Atlas [mailto:[email-masked]]
Sent: Tuesday, June 13, 2017 2:18 PM
To: Alexander Vainshtein
Cc: Naiming Shen (naiming); Les Ginsberg (ginsberg); [email-masked]; RFC Errata System; [email-masked]; [email-masked]; Alvaro Retana (aretana); [email-masked]; [email-masked]
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

From the discussion, it sounds like there is a problem and the argument is about
what layer it should be handled by.  Perhaps, instead of normative text, it could be
a note?

Regards,
Alia

On Sun, May 7, 2017 at 1:35 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
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<tel:+972%203-926-6302>
Cell:      +972-549266302<tel:+972%2054-926-6302>
Email:   [email-masked]<mailto:[email-masked]>

From: Naiming Shen (naiming) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, May 05, 2017 8:44 AM

To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
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]>
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

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

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)) {

                                         return 0;

                                         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:          /*

                                          */

                                         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<http://192.168.1.35/24>) <—> vaio (enp2s8 with IP 192.168.2.100/24<http://192.168.2.100/24>)

on vaio: I run an arping to request ARP resolution of 192.168.1.35<http://192.168.1.35>:

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

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

Best Regards,
- Naiming

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

Naiming,

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<tel:+972%203-926-6302>
Cell:      +972-549266302<tel:+972%2054-926-6302>
Email:   [email-masked]<mailto:[email-masked]>

From: Naiming Shen (naiming) [mailto:[email-masked]]
Sent: Monday, May 01, 2017 5:34 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
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]>
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander,

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,

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:

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.

Regards,
Sasha

Office: +972-39266302<tel:+972%203-926-6302>
Cell:      +972-549266302<tel:+972%2054-926-6302>
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

> From: Isis-wg [mailto:[email-masked]] On Behalf Of RFC
> Errata System
> 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>
> Reported by: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
>
> Section: 4.3
>
> Original Text
> -------------
> 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.
> o          Are assigned with IP addresses and subnet masks yielding different
> subnets
> because ARP will not resolve addresses assigned to the corresponding interfaces.
>
> Instructions:
> -------------
> Title               : Point-to-Point Operation over LAN in Link State Routing
> Protocols
> [email-masked]<mailto:[email-masked]>

___________________________________________________________________________

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.
___________________________________________________________________________

___________________________________________________________________________

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: Hannes Gredler <[email-masked]>
Date: Wed, 14 Jun 2017 15:02:30 +0200

hi alia,

the issue at hand IMO does not warrant an errata.

this is more related to how ARP & nexthop handling
is performed internally in a routing-stack which is IMO a bit outside
of what isis-wg should work on.

/hannes

On 6/13/17 23:18, Alia Atlas wrote:
> On Sun, May 7, 2017 at 1:35 AM, Alexander Vainshtein
> <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     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. ____
> 
>     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 <tel:+972%203-926-6302>____
> 
>     Cell:      +972-549266302 <tel:+972%2054-926-6302>____
> 
>     <mailto:[email-masked]>____
> 
>     __ __
> 
>     *From:*Naiming Shen (naiming) [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Alexander Vainshtein <[email-masked]
>     <mailto:[email-masked]>>
>     *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]>
>     *Subject:* Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)____
> 
>     __ __
> 
>     __ __
> 
>     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 <http://192.168.1.35/24>) <—>
>     vaio (enp2s8 with IP 192.168.2.100/24 <http://192.168.2.100/24>)____
> 
>     __ __
> 
>     on vaio: I run an arping to request ARP resolution of 192.168.1.35
>     <http://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____
> 
>     __ __
> 
>     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____
> 
>     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,____
> 
>         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 <tel:+972%203-926-6302>____
> 
>         Cell:      +972-549266302 <tel:+972%2054-926-6302>____
> 
>         <mailto:[email-masked]>____
> 
>          ____
> 
>         *To:* Alexander Vainshtein <[email-masked]
>         <mailto:[email-masked]>>
>         *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]>
>         *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 <tel:+972%203-926-6302>____
> 
>             Cell:      +972-549266302 <tel:+972%2054-926-6302>____
> 
>             <mailto:[email-masked]>____
> 
>              ____
> 
>              ____
> 
>             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-----____
> 
>             <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]>;____
> 
>             <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>____
> 
> 
>             _______________________________________________________________________________
> 
>          ____
> 
> 
>         _______________________________________________________________________________
> 
>     __ __
> 
>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Jun 2017 10:59:10 -0400

> of what isis-wg should work on.

I agree that it is a bit outside the scope - but the issue comes up
from interactions.   I am happy to reject the errata, if that is the
consensus, but I could use a clearly written note explaining why.
I'm also fine with having it become an advisory note; I think it is
useful to provide non-normative guidance.

Regards,
Alia

> >     <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/dev_net
> >(in_dev->dev);____
> >
> >                         int scope
> >     <http://elixir.free-electrons.com/linux/latest/ident/RT_SCOPE_HOST
> >;____
> >
> >                                              break;____
> >
> >                         case 2:          /*____
> >
> >                                              * Reply only if tip is
> >     <http://elixir.free-electrons.com/linux/latest/ident/RT_SCOPE_HOST
> >;____
> >
> >                                              break;____
> >
> >             <http://webdefence.global.blackspider.com/urlwrap/?q=
> AXicE3RmiL7GwDDlCANDUU6lgUmSXnFRmV5uYmZOcn5eSVF-
> jl5yfi5DmYmhUUREcLmBkaGRuQmDY05qRWJeSmqRXlhiZl5xRklqZp5DanJm
> SWpOKlh9RklJgZW-fmpKZkl-kV5-UToDA0PFQQYGAOFQJGs&Z>____
> >
> ___________________
> ___________________

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 14 Jun 2017 17:34:37 +0000

Alia –

Try this:

“RFC 5309 introduced the possibility of supporting an unnumbered configuration on a LAN. Statements in this RFC regarding ARP concerns are therefore deliberately limited to this new configuration.

For IS-IS, RFC 3787 Section 10 discusses concerns regarding mismatched subnets on numbered links.

For OSPF it is well known that there are some existing implementations which have supported mismatched subnets for many years.

Any concerns with ARP behavior  in support of mismatched subnets on numbered LANs is out of scope of RFC 5309.”

   Les

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, June 14, 2017 7:59 AM
To: Hannes Gredler
Cc: Alexander Vainshtein; Naiming Shen (naiming); Les Ginsberg (ginsberg); [email-masked]; RFC Errata System; [email-masked]; [email-masked]; Alvaro Retana (aretana); [email-masked]
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

On Wed, Jun 14, 2017 at 9:02 AM, Hannes Gredler <[email-masked]<mailto:[email-masked]>> wrote:
hi alia,

Regards,
Alia

/hannes

On 6/13/17 23:18, Alia Atlas wrote:
> <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Naiming,____
>
>     Office: +972-39266302<tel:%2B972-39266302> <tel:+972%203-926-6302>____
>
>     Cell:      +972-549266302<tel:%2B972-549266302> <tel:+972%2054-926-6302>____
>
>     <mailto:[email-masked]<mailto:[email-masked]>>____
>
>     __ __
>
>     *From:*Naiming Shen (naiming) [mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>]
>     *To:* Alexander Vainshtein <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     *Cc:* Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>; RFC Errata System
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>;
>     Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     lenovo (enp3s0 with IP 192.168.1.35/24<http://192.168.1.35/24> <http://192.168.1.35/24>) <—>
>     vaio (enp2s8 with IP 192.168.2.100/24<http://192.168.2.100/24> <http://192.168.2.100/24>)____
>
>     __ __
>
>         <[email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>> wrote:____
>
>         __ __
>
>         Naiming,____
>
>         Office: +972-39266302<tel:%2B972-39266302> <tel:+972%203-926-6302>____
>
>         Cell:      +972-549266302<tel:%2B972-549266302> <tel:+972%2054-926-6302>____
>
>         <mailto:[email-masked]<mailto:[email-masked]>>____
>
>          ____
>
>         *From:* Naiming Shen (naiming) [mailto:[email-masked]<mailto:[email-masked]>]
>         *To:* Alexander Vainshtein <[email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>>
>         *Cc:* Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>; RFC Errata System
>         <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>         [email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>; Alvaro Retana (aretana)
>         <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>
>             <[email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>> wrote:____
>
>              ____
>
>             Les,____
>
>             Office: +972-39266302<tel:%2B972-39266302> <tel:+972%203-926-6302>____
>
>             Cell:      +972-549266302<tel:%2B972-549266302> <tel:+972%2054-926-6302>____
>
>             <mailto:[email-masked]<mailto:[email-masked]>>____
>
>              ____
>
>              ____
>
>             From: Les Ginsberg (ginsberg) [mailto:[email-masked]<mailto:[email-masked]>]
>             To: RFC Errata System <[email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>>; Naiming Shen (naiming)
>             <[email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>>;[email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>; Alvaro Retana (aretana)
>             <[email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>
>             Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>
>             > From: Isis-wg [mailto:[email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>] On Behalf Of RFC____
>
>             > Errata System____
>
>             > To: Naiming Shen (naiming); [email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>;____
>
>             > [email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>; Alvaro Retana (aretana);____
>
>             > [email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>____
>
>             > Cc: [email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>;____
>
>             > rfc-editor@rfc- editor.org<http://editor.org>
>             > Reported by: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>
>             <mailto:[email-masked]<mailto:[email-masked]>>>____
>
>             > ____
>
>             > Section: 4.3____
>
>             > ____
>
>             > Original Text____
>
>             > -------------____
>
>             > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>____
>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Jun 2017 13:39:52 -0400

Les,

Thanks!   I'll let this sit for a day or so to see if there are more
comments
and then reject the errata with this note.

Regards,
Alia

On Wed, Jun 14, 2017 at 1:34 PM, Les Ginsberg (ginsberg) <[email-masked]
> wrote:

> Alia –
>
>
>
> Try this:
>
>
>
> “RFC 5309 introduced the possibility of supporting an unnumbered
> configuration on a LAN. Statements in this RFC regarding ARP concerns are
> therefore deliberately limited to this new configuration.
>
>
>
> For OSPF it is well known that there are some existing implementations
> which have supported mismatched subnets for many years.
>
>
>
> Any concerns with ARP behavior  in support of mismatched subnets on
> numbered LANs is out of scope of RFC 5309.”
>
>
>
>    Les
>
>
>
>
>
> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Wednesday, June 14, 2017 7:59 AM
> *To:* Hannes Gredler
> *Cc:* Alexander Vainshtein; Naiming Shen (naiming); Les Ginsberg
> (ginsberg); [email-masked]; RFC Errata System;
> [email-masked]; [email-masked]; Alvaro Retana (aretana);
> [email-masked]
> >     Office: +972-39266302 <tel:+972%203-926-6302 <+972%203-926-6302>
> >____
> >
> >     Cell:      +972-549266302 <tel:+972%2054-926-6302
> <+972%2054-926-6302>>____
> >
> >     <http://kb.linuxvirtualserver.org/wiki/
> Using_arp_announce/arp_ignore_to_disable_ARP>____
> >
> >     __ __
> >
> >         Office: +972-39266302 <tel:+972%203-926-6302 <+972%203-926-6302>
> >____
> >
> >         Cell:      +972-549266302 <tel:+972%2054-926-6302
> <+972%2054-926-6302>>____
> >
> >             Office: +972-39266302 <tel:+972%203-926-6302
> <+972%203-926-6302>>____
> >
> >             Cell:      +972-549266302 <tel:+972%2054-926-6302
> <+972%2054-926-6302>>____
> >

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 15 Jun 2017 07:11:39 +0000

Alia, Les and all,
The note proposed by Les looks OK to me.

Regards,
Sasha

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

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, June 14, 2017 8:40 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Hannes Gredler <[email-masked]>; Alexander Vainshtein <[email-masked]>; Naiming Shen (naiming) <[email-masked]>; [email-masked]; RFC Errata System <[email-masked]>; [email-masked]; Alvaro Retana (aretana) <[email-masked]>; [email-masked]
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Les,

Thanks!   I'll let this sit for a day or so to see if there are more comments
and then reject the errata with this note.

Regards,
Alia

On Wed, Jun 14, 2017 at 1:34 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Alia –

Try this:

   Les

From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, June 14, 2017 7:59 AM
To: Hannes Gredler
Cc: Alexander Vainshtein; Naiming Shen (naiming); Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>; RFC Errata System; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana); [email-masked]<mailto:[email-masked]>
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Regards,
Alia

/hannes

On 6/13/17 23:18, Alia Atlas wrote:
>             > rfc-editor@rfc- editor.org<http://webdefence.global.blackspider.com/urlwrap/?q=AXicE3RmiL7GwDDlCANDUU6lgWGSXnFRmV5uYmZOcn5eSVF-jl5yfi5DmamrR0pRaaaBsaW5hQGDY05qRWJeSmqRXlhiZl5xRklqZp5DanJmSWpOKlh9RklJgZW-fmpKZkl-kV5-UToDA0PFQQYGAP3EJNg&Z>