Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN?
Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 13 November 2019 19:39 UTC
Return-Path: <brian.e.carpenter@gmail.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 64AB612084A for <v6ops@ietfa.amsl.com>; Wed, 13 Nov 2019 11:39:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 kxc70TMT4pPy for <v6ops@ietfa.amsl.com>; Wed, 13 Nov 2019 11:39:09 -0800 (PST)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 E34DB12003E for <v6ops@ietf.org>; Wed, 13 Nov 2019 11:39:09 -0800 (PST)
Received: by mail-pf1-x42d.google.com with SMTP id q26so2306414pfn.11 for <v6ops@ietf.org>; Wed, 13 Nov 2019 11:39:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tLO5SyB80+Mb5rLn4j+090TIUbPJAq7qczuportTdf4=; b=t40gokhPEC0tmkRDEfLXFsEAxcEz99jCqDWTEP2OSBEAJRe03UIccGfeycvT1JS4uz iW+acJMDasTkpixS9nfbEYddP5ndIV0KYtZ6L+Iwe0Ptrd0yGGaQg0Ng0z0E0SW4wCsb NN+MES/5my602oYJs7ESXsDwwPoIx1vD2xlIoomPIJb3yDHVe8MTVqe3N7U54x7DGmT2 7kNbDk+o5QXN7Cp1m/BnkH6HXGePdTMHsjsjJYkzNNpfwCBPeVP+S2eaNLLcvK0gZLRL ZeEcqMAEJoMpRIwBd2WiLxrLM404kBBSCOxZQPKxnFlRfwJ4IU0pLLtPmy/5oB/BAOjO J9zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tLO5SyB80+Mb5rLn4j+090TIUbPJAq7qczuportTdf4=; b=eTtHA+6VU9wGNSKiDrlU2NdUc1g4oldM1JsM01sWmoMo0ajMqGthAybThx0mZgSbPE mMyHVQYwBUew2Z9nEPOrJ8Z1/rxkGoc02c+//GXJPIbdit4XbkN6NjFw3+SrJ9driy4E v6UMRhhXDQ0CFdahvYTzwpDJ7zIpTND3Ny+OU3ADuBzb08emuf1fxvHK6QakZFx7+a5m U1lQXKdPnpRyrDOPX1bJbJH6he0QlfpUIIvB48Lk4ePjkezYF0ALYIOdn9b1Wg3p92uC Eq9XE8Vhg0zOWftkoBvikqstBim6L/ooDSAD1b5jv31qMm6o0jOft3kLt3X5eoVW6Iz4 4GMg==
X-Gm-Message-State: APjAAAU9X5Z8+oh2l9tjctSPOTyr2WPjbVOkaQWmn9aHQwzdxRgPfRpC aUnimT1HzrvQ+gUZg1TFUAM0GQq8
X-Google-Smtp-Source: APXvYqxZzK5DWic3cJ/N1IbFZBeWGJAjDM7J2Y4GOZIM7e9QexpfR7XAT6RLnqUF4spPC3N5UAA5zg==
X-Received: by 2002:aa7:961d:: with SMTP id q29mr6226455pfg.89.1573673949113; Wed, 13 Nov 2019 11:39:09 -0800 (PST)
Received: from [192.168.178.30] (8.166.69.111.dynamic.snap.net.nz. [111.69.166.8]) by smtp.gmail.com with ESMTPSA id l21sm3035508pjt.28.2019.11.13.11.39.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 11:39:08 -0800 (PST)
To: Timothy Winters <twinters@iol.unh.edu>, Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
References: <c4791cdd-6021-de83-6863-4d77ef1d1694@gmail.com> <CAOSSMjWu7C9jmG+8Yg7V++3GWzG+BSzFu0o0nHHYJY60P2T2oA@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com>
Date: Thu, 14 Nov 2019 08:39:06 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAOSSMjWu7C9jmG+8Yg7V++3GWzG+BSzFu0o0nHHYJY60P2T2oA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/YZzX4mr-BvwnnWC-D2EK_S2Uy8s>
Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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, 13 Nov 2019 19:39:11 -0000
On 14-Nov-19 03:16, Timothy Winters wrote: > Hi Alex, > > On Wed, Nov 13, 2019 at 2:54 AM Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote: > >> Hi, v6opsers, >> >> While reading through RFC7084 I couldnt find a place where the CE Router is mandated to put a prefix in the PIO, even though there is a (strange?) requirement to use RIO. >> >> I would like to ask: >> >> - which existing particular requirement the author assumes to be putting a derived /64 in the PIO in the RA? > > The placing of the prefixes in the PIO from the IA_PD was originally located in RFC 3633, so it's not covered in 7084. More to the point of Alex's question, 7084 says: >>> The IPv6 CE router MUST support router behavior according to >>> Neighbor Discovery for IPv6 [RFC4861]. which therefore requires properly formed PIOs. >> >> - what does it mean 'An IPv6 CE router MUST advertise itself as a router for the delegated prefix(es) [...] using the "Route Information Option" specified in Section 2.3 of [RFC4191].'? (I am asking because I suspect this requirement is wrong: the CE Router must certainly not use RIO with these prefixes). Why is that wrong? It is under "LAN requirements:" and seems to mean exactly what Alex says next: >> CE Routers should place the RIO in the RAs on the LAN interface to have Host route traffic for those prefixes to that Router if they have multi-homed (Although, not surprisingly, I would like to see RFC8028 mandated too.) Regards Brian >> >> Alex > > Regards, > Tim
- [v6ops] RFC7084 - absence of req of prefix presen… Alexandre Petrescu
- Re: [v6ops] RFC7084 - absence of req of prefix pr… Timothy Winters
- Re: [v6ops] RFC7084 - absence of req of prefix pr… Brian E Carpenter
- Re: [v6ops] RFC7084 - absence of req of prefix pr… STARK, BARBARA H
- Re: [v6ops] RFC7084 - absence of req of prefix pr… Mark Smith
- Re: [v6ops] RFC7084 - absence of req of prefix pr… Alexandre Petrescu
- Re: [v6ops] RFC7084 - absence of req of prefix pr… Alexandre Petrescu
- Re: [v6ops] RFC7084 - absence of req of prefix pr… Alexandre Petrescu
- Re: [v6ops] RFC7084 - absence of req of prefix pr… Brian E Carpenter
- Re: [v6ops] RFC7084 - absence of req of prefix pr… Mark Smith
- Re: [v6ops] RFC7084 - absence of req of prefix pr… Alexandre Petrescu
- Re: [v6ops] RFC7084 - absence of req of prefix pr… Alexandre Petrescu