Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast

"Fred Baker (fred)" <> Wed, 08 July 2015 19:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 75E151A8700 for <>; Wed, 8 Jul 2015 12:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -114.511
X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1zAAmISraEcU for <>; Wed, 8 Jul 2015 12:09:25 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB1CB1A86FD for <>; Wed, 8 Jul 2015 12:09:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3716; q=dns/txt; s=iport; t=1436382566; x=1437592166; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cI7jbwS70PRT2zwCiY+/2x76jvFt4c/kwJl8j9vgnJE=; b=DV5pFEg5OBIZi6oTz59LqACCJgWzyLu091RuQLQXraI7BOP8Jv4P1OzC o3ai5RPGO1X18fc/uTM/HZo7UFl7l9zjvpWx3BTctdDA68TPfLbdHgtlT lxdf7wPWl+kMArT0nG78lXVK0HpFUcLHXS1s/tYV25vvO/nGQbaSvgYqM 0=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,433,1432598400"; d="asc'?scan'208";a="166790606"
Received: from ([]) by with ESMTP; 08 Jul 2015 19:09:25 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t68J9Odm012470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jul 2015 19:09:24 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 8 Jul 2015 14:09:24 -0500
From: "Fred Baker (fred)" <>
To: "" <>
Thread-Topic: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast
Thread-Index: AQHQubGaJQ06k0kTHEW5THWdn9BT9A==
Date: Wed, 8 Jul 2015 19:09:24 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_2EBA5662-25D3-41E7-9682-7BA15690A5EC"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: <>
Cc: v6ops list <>
Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jul 2015 19:09:27 -0000

Lorenzo and Andrew:

I'm trying to figure out how to unjam the Prague agenda, and I wonder if this (very simple) draft can be sorted out on the list before the event. We already have two supportive comments. I'll note that what you describe for IPv6 is pretty common in IPv4 today - and I have it in my head it is common in IPv6 today. What I think you're saying is "please make it common if it's not".

RFC 4861, section 6.2.6, says:

   In addition to sending periodic, unsolicited advertisements, a router
   sends advertisements in response to valid solicitations received on
   an advertising interface.  A ROUTER MAY CHOOSE TO UNICAST THE
   solicitation's source address is not the unspecified address), but
   the usual case is to multicast the response to the all-nodes group.
   In the latter case, the interface's interval timer is reset to a new
   random value, as if an unsolicited advertisement had just been sent
   (see Section 6.2.4).

emphasis mine.

Your draft says, if I may summarize in two sentences, "routers that don't send unicast RAs in response to an RS cost the network and its hosts a lot of resources" and "please send RAs unicast unless there is a good reason not to, such as a periodic RA".


If I were to give you an agenda slot, did I just say everything (modulo perhaps a supporting graphic) that you would say?

Presuming the answer to be "yes", let me propose a short-circuit process. I would invite immediate discussion - do we agree with this? Is there an alternative viewpoint we're missing? Are there other cases the draft should address (it's primarily about mobile, but I would submit it is relevant to any shared L2 infrastructure, which could describe data centers and WiFi networks)?

BTW, chair hat off, I would suggest that your proposed configuration knob default to "send unicast", not "send multicast".  Take that as you see fit. I have been wrong before.

Given an avalanche of "yes, and let's make it a WG document, but here's a comment", I'd suggest that
 - I don't give the authors a meeting slot
 - We accept this as a working group document
 - The authors post the updated draft as draft-ietf-v6ops-solicited-ra-unicast in August
 - I run a WGLC in September
 - we ship it