Re: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-conditional-ras-05: (with COMMENT)
Adam Roach <adam@nostrum.com> Wed, 01 August 2018 16:04 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A23130E6F; Wed, 1 Aug 2018 09:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 V9YwV7MkSPT3; Wed, 1 Aug 2018 09:04:14 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 80C21130E2E; Wed, 1 Aug 2018 09:04:14 -0700 (PDT)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w71G47nD077941 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 1 Aug 2018 11:04:10 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: Jen Linkova <furry13@gmail.com>
Cc: The IESG <iesg@ietf.org>, Russ White <russ@riw.us>, v6ops-chairs@ietf.org, V6 Ops List <v6ops@ietf.org>, draft-ietf-v6ops-conditional-ras@ietf.org
References: <153310803137.22145.5132532082101433230.idtracker@ietfa.amsl.com> <CAFU7BAR4cmp1qxa-OEsFz_cocAuu1AvV_2r_q-x9RHGqbSHNbw@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <fa65cc26-3505-955e-c85d-c03db4fd4b36@nostrum.com>
Date: Wed, 01 Aug 2018 11:04:06 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CAFU7BAR4cmp1qxa-OEsFz_cocAuu1AvV_2r_q-x9RHGqbSHNbw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/O1U8Q8-WFl2sajcfQiM2B_7GlBs>
Subject: Re: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-conditional-ras-05: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2018 16:04:20 -0000
On 8/1/18 6:55 AM, Jen Linkova wrote: > Hi Adam, > > On Wed, Aug 1, 2018 at 5:20 PM, Adam Roach <adam@nostrum.com> wrote: >> §3.3.1: >> >>> It should be noted that in IPv4 multihoming with NAT, when the egress >>> interface is chosen without taking packet source address into account >>> (as internal hosts usually have addresses from [RFC1918] space), >>> sessions can not be preserved after an uplink recovery. >> This isn't necessarily true. For example, if the NAT is tracking which >> ISP-facing interface is associated with a given established session, the >> sessions will survive restoration of an uplink. I have exactly such an IPv4 >> multi-homing configuration working on my home network (with RFC 1918 addresses >> assigned to all local devices), and will happily share details of my >> configuration with interested parties. >> >> I propose striking this paragraph from the document. > Good point. I've rephrased it to > "It should be noted that in IPv4 multihoming with NAT, when the egress > interface is chosen without taking packet source address into account > (as internal hosts usually have addresses from [RFC1918] space), > sessions might not be preserved after an uplink recovery unless > packet forwarding is integrated with existing NAT sessions tracking." > > https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-3.3.1 > > Would it address your concern? It does. Thanks. /a