Re: [Technical Errata Reported] RFC5309 (5007)
Alia Atlas <[email protected]>
| Newsgroups | gmane.ietf.isis |
|---|---|
| Message-ID | <CAG4d1rd+9Do-s7tvBaeY29RwajAP5FCfFQtXF6C4yTb4hc1TkA@mail.gmail.com> |
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 protected] > 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 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 protected]] > *Sent:* Wednesday, June 14, 2017 7:59 AM > *To:* Hannes Gredler > *Cc:* Alexander Vainshtein; Naiming Shen (naiming); Les Ginsberg > (ginsberg); [email protected]; RFC Errata System; > [email protected]; [email protected]; Alvaro Retana (aretana); > [email protected] > *Subject:* Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007) > > > > On Wed, Jun 14, 2017 at 9:02 AM, Hannes Gredler <[email protected]> wrote: > > 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. > > > > 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 > > > > > > > /hannes > > On 6/13/17 23:18, Alia Atlas wrote: > > 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 protected] > > <mailto:[email protected]>> 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 <+972%203-926-6302> > >____ > > > > Cell: +972-549266302 <tel:+972%2054-926-6302 > <+972%2054-926-6302>>____ > > > > Email: [email protected] > > <mailto:[email protected]>____ > > > > __ __ > > > > *From:*Naiming Shen (naiming) [mailto:[email protected] > > <mailto:[email protected]>] > > *Sent:* Friday, May 05, 2017 8:44 AM > > > > > > *To:* Alexander Vainshtein <[email protected] > > <mailto:[email protected]>> > > *Cc:* Les Ginsberg (ginsberg) <[email protected] > > <mailto:[email protected]>>; [email protected] > > <mailto:[email protected]>; RFC Errata System > > <[email protected] <mailto:[email protected]>>; > > [email protected] > > <mailto:[email protected]>; [email protected] > > <mailto:[email protected]>; [email protected] <mailto:[email protected]>; > > Alvaro Retana (aretana) <[email protected] > > <mailto:[email protected]>>; [email protected] > > <mailto:[email protected]>; [email protected] <mailto: > [email protected]> > > *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 > > <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 > > <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____ > > > > __ __ > > > > 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 protected] > > <mailto:[email protected]>> 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 <+972%203-926-6302> > >____ > > > > Cell: +972-549266302 <tel:+972%2054-926-6302 > <+972%2054-926-6302>>____ > > > > Email: [email protected] > > <mailto:[email protected]>____ > > > > ____ > > > > *From:* Naiming Shen (naiming) [mailto:[email protected]] > > *Sent:* Monday, May 01, 2017 5:34 AM > > *To:* Alexander Vainshtein <[email protected] > > <mailto:[email protected]>> > > *Cc:* Les Ginsberg (ginsberg) <[email protected] > > <mailto:[email protected]>>; [email protected] > > <mailto:[email protected]>; RFC Errata System > > <[email protected] <mailto:[email protected]>>; > > [email protected] > > <mailto:[email protected]>; [email protected] > > <mailto:[email protected]>; [email protected] > > <mailto:[email protected]>; Alvaro Retana (aretana) > > <[email protected] <mailto:[email protected]>>; > > [email protected] <mailto:[email protected]>; [email protected] > > <mailto:[email protected]> > > *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 protected] > > <mailto:[email protected]>> 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 > <+972%203-926-6302>>____ > > > > Cell: +972-549266302 <tel:+972%2054-926-6302 > <+972%2054-926-6302>>____ > > > > Email: [email protected] > > <mailto:[email protected]>____ > > > > ____ > > > > ____ > > > > -----Original Message----- > > From: Les Ginsberg (ginsberg) [mailto:[email protected]] > > Sent: Sunday, April 30, 2017 5:19 PM > > To: RFC Errata System <[email protected] > > <mailto:[email protected]>>; Naiming Shen (naiming) > > <[email protected] > > <mailto:[email protected]>>;[email protected] > > <mailto:[email protected]>; [email protected] > > <mailto:[email protected]>; [email protected] > > <mailto:[email protected]>; Alvaro Retana (aretana) > > <[email protected] > > <mailto:[email protected]>>; [email protected] > > <mailto:[email protected]>; [email protected] > > <mailto:[email protected]> > > Cc: Alexander Vainshtein <[email protected] > > <mailto:[email protected]>>; [email protected] > > <mailto:[email protected]> > > 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 protected] > > <mailto:[email protected]>] On Behalf Of RFC____ > > > > > Errata System____ > > > > > Sent: Sunday, April 30, 2017 1:16 AM____ > > > > > To: Naiming Shen (naiming); [email protected] > > <mailto:[email protected]>;____ > > > > > [email protected] > > <mailto:[email protected]>; [email protected] > > <mailto:[email protected]>; Alvaro Retana (aretana);____ > > > > > [email protected] > > <mailto:[email protected]>; [email protected] > > <mailto:[email protected]>____ > > > > > Cc: [email protected] > > <mailto:[email protected]>; [email protected] > > <mailto:[email protected]>;____ > > > > > rfc-editor@rfc- editor.org > > <http://webdefence.global.blackspider.com/urlwrap/?q= > AXicE3RmiL7GwDDlCANDUU6lgUmSXnFRmV5uYmZOcn5eSVF- > jl5yfi5DmYmhUUREcLmBkaGRuQmDY05qRWJeSmqRXlhiZl5xRklqZp5DanJm > SWpOKlh9RklJgZW-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 > > <http://www.rfc-editor.org/errata_search.php?rfc=5309& > eid=5007>____ > > > > > ____ > > > > > --------------------------------------____ > > > > > Type: Technical____ > > > > > Reported by: Alexander Vainshtein < > [email protected] > > <mailto:[email protected]>>____ > > > > > ____ > > > > > 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 protected] <mailto:[email protected]>____ > > > > > https://www.ietf.org/mailman/listinfo/isis-wg > > <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. > > ___________________________________________________________ > ________________ > > > > > > > _______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg