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

Alia Atlas <akatlas@gmail.com> Tue, 13 June 2017 21:18 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD7E13010C for <isis-wg@ietfa.amsl.com>; Tue, 13 Jun 2017 14:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnh6VDF8M_0B for <isis-wg@ietfa.amsl.com>; Tue, 13 Jun 2017 14:18:07 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D6D12FEEB for <isis-wg@ietf.org>; Tue, 13 Jun 2017 14:18:06 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id 36so39852605wry.3 for <isis-wg@ietf.org>; Tue, 13 Jun 2017 14:18:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HsR8nvXs5o5qsehwyEgQh8qssUH9RWDn52EeNhDTwHI=; b=SB0rDyfl2w9sPcoEa0NR6v/rjLIJ2MoADr+insP9kKjw5rkf+L4Qw3s00wj0wTy4hI AtoJ7/V4MJkkXi/uIvIwi/Fs/oJ6WCZ5F18V5HeRuQ/3dKdJAVA15sVFQ+Sx+ZngemwV b4Z9vBvITY7Jipyf7YL7qPnNvn8rR0C+X3ax7mABRexuwqV435wJLm1bJLNB7s0uO+pr eq6sWWalxfR0M+g3XlBMfyf15u4ihyOzThCGo8/GwcuhNuF8SIBh2T1FHdg/lChU7gzV b7K70LpJpsIIUJ8fmbjoroe/asj4gjfh5FsXDtl48FJMi+MPHt8Be3u633kFxSPxsISi I/sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HsR8nvXs5o5qsehwyEgQh8qssUH9RWDn52EeNhDTwHI=; b=F43UhyIN6eR5MiC4IH1Lh/5yp80ziRSAY3jXMoiDUAnK7scLQ2JFNVld0Tb1o/yJxe qdj9AwjY6LifepYy0WxMNS9lckla5FqjP156LOclqNJ0ESeZuC8RkQFrjz+0SMLeSM31 PZML2eNzQhpTjzEOvlwtl/Vad/ZNzG7mCPD3mCK+Hhr4gG1T0skpU/WFwPA2RfX9Lx9P z4VXjtgCnjR5sIHg0s/JMtoh/CQ5xNVzKr28lwn8TG5gg3PD8UgvWPmfK1zT0wfQ70aC +pkL+iVvDFLmo3G3q5KQX1Ew6qcxr+u38LmNFiePLayaFhdWjPxnd0Ds9LNesf2qjwMw vMaA==
X-Gm-Message-State: AKS2vOzAHksIsce/clKp2x74DVBGUDk4eaNJIAYI6x9HkK0gjFzQx6Zb UNsZrae2XorpCWWAWnE96G7/vYaFYrsG
X-Received: by 10.28.19.11 with SMTP id 11mr12633657wmt.123.1497388684780; Tue, 13 Jun 2017 14:18:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.131.66 with HTTP; Tue, 13 Jun 2017 14:18:03 -0700 (PDT)
In-Reply-To: <HE1PR03MB1722501D2C6E614E8551AD319DE90@HE1PR03MB1722.eurprd03.prod.outlook.com>
References: <20170430081555.026C1B8183C@rfc-editor.org> <bd426412060143b18b888f9fb9135728@XCH-ALN-001.cisco.com> <AM4PR03MB171368B3A0BC936159ABE14A9D150@AM4PR03MB1713.eurprd03.prod.outlook.com> <F45DED94-22FE-436D-A2E9-AD01AB454832@cisco.com> <AM4PR03MB171381904BE473010383FAD89D140@AM4PR03MB1713.eurprd03.prod.outlook.com> <5C8FC259-C018-4542-B77D-F23BC3E212A9@cisco.com> <HE1PR03MB1722501D2C6E614E8551AD319DE90@HE1PR03MB1722.eurprd03.prod.outlook.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Tue, 13 Jun 2017 17:18:03 -0400
Message-ID: <CAG4d1reBKcwk0UZVvQgOoLhWramwcqtjPOXegcg5ubnRJsOkiQ@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: "Naiming Shen (naiming)" <naiming@cisco.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>, "alex.zinin@alcatel-lucent.com" <alex.zinin@alcatel-lucent.com>, "db3546@att.com" <db3546@att.com>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "chopps@chopps.org" <chopps@chopps.org>, "hannes@gredler.at" <hannes@gredler.at>
Content-Type: multipart/alternative; boundary="001a1145b986a5af560551ddf8bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/zs_SgI_sMNXe3GbDRKCjNIrUutI>
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jun 2017 21:18:14 -0000

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 <
Alexander.Vainshtein@ecitele.com> 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:   Alexander.Vainshtein@ecitele.com
>
>
>
> *From:* Naiming Shen (naiming) [mailto:naiming@cisco.com]
> *Sent:* Friday, May 05, 2017 8:44 AM
>
> *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>; isis-wg@ietf.org; RFC
> Errata System <rfc-editor@rfc-editor.org>rg>; alex.zinin@alcatel-lucent.com;
> akatlas@gmail.com; db3546@att.com; Alvaro Retana (aretana) <
> aretana@cisco.com>gt;; chopps@chopps.org; hannes@gredler.at
> *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 <
> Alexander.Vainshtein@ecitele.com> 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:   Alexander.Vainshtein@ecitele.com
>
>
>
> *From:* Naiming Shen (naiming) [mailto:naiming@cisco.com
> <naiming@cisco.com>]
> *Sent:* Monday, May 01, 2017 5:34 AM
> *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>; isis-wg@ietf.org; RFC
> Errata System <rfc-editor@rfc-editor.org>rg>; alex.zinin@alcatel-lucent.com;
> akatlas@gmail.com; db3546@att.com; Alvaro Retana (aretana) <
> aretana@cisco.com>gt;; chopps@chopps.org; hannes@gredler.at
> *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 <
> Alexander.Vainshtein@ecitele.com> 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:   Alexander.Vainshtein@ecitele.com
>
>
>
>
>
> -----Original Message-----
> From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com
> <ginsberg@cisco.com>]
> Sent: Sunday, April 30, 2017 5:19 PM
> To: RFC Errata System <rfc-editor@rfc-editor.org>rg>; Naiming Shen (naiming)
> <naiming@cisco.com>;alex.zinin@alcatel-lucent.com; akatlas@gmail.com;
> db3546@att.com; Alvaro Retana (aretana) <aretana@cisco.com>om>; chopps@
> chopps.org; hannes@gredler.at
> Cc: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>om>;
> isis-wg@ietf.org
> 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:isis-wg-bounces@ietf.org
> <isis-wg-bounces@ietf.org>] On Behalf Of RFC
>
> > Errata System
>
> > Sent: Sunday, April 30, 2017 1:16 AM
>
> > To: Naiming Shen (naiming); alex.zinin@alcatel-lucent.com;
>
> > akatlas@gmail.com; db3546@att.com; Alvaro Retana (aretana);
>
> > chopps@chopps.org; hannes@gredler.at
>
> > Cc: Alexander.Vainshtein@ecitele.com; isis-wg@ietf.org;
>
> > 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 <Alexander.Vainshtein@ecitele.com>
>
> >
>
> > 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
>
> > Isis-wg@ietf.org
>
> > 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.
> ____________________________________________________________
> _______________
>