Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

Arturo Servin <arturo.servin@gmail.com> Thu, 24 October 2013 15:00 UTC

Return-Path: <arturo.servin@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 18A5E11E8349 for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2013 08:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv+IZ5HRleqH for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2013 08:00:08 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9B29811E8355 for <v6ops@ietf.org>; Thu, 24 Oct 2013 07:56:53 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id ey11so2690327wid.7 for <v6ops@ietf.org>; Thu, 24 Oct 2013 07:56:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BCv/72zh4CCV5ujU3+VY4k5wxgBo5lto5JDCXtmAfkM=; b=f4yslWTT0yX2EDCt7aRUS5M/Uo0O9GNjBGRrKX2iMbxamGUuFG8L3Hvex8Qyv3/5kp MEFjK7lumis2CWPjgQmLM7bvbnhtXKVFBYhfvsQX6eJVlXxtxQjwda0KBBmLQ8qxtows MHC+8V/+e1QSEixGtS4rLz8mzFOd1F3tev8OpnmWZzCcb+OL/tXXI5tAOPelvGmi3kOp /QQIMVz3uEpeJT1oZ63hj1ojK9bWugjB7hRqKjrcfx+q6f1lJFymKqF/2FneGEvO249s rrEZqqAJqnO8h8nbQnraiuhEsdnIeiYt+y9TYIp+HTC4Me4tFmfmBySCIewV8CkyIRwq l47g==
X-Received: by 10.194.219.70 with SMTP id pm6mr2987327wjc.47.1382626609388; Thu, 24 Oct 2013 07:56:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.42.4 with HTTP; Thu, 24 Oct 2013 07:56:29 -0700 (PDT)
In-Reply-To: <CE8E8EC3.59F3A%victor@jvknet.com>
References: <CAKD1Yr0ky0SSrhYz9R82bTO+GhrsBVL-_Uf-9sbYuLWKYpmi0Q@mail.gmail.com> <CE8E8EC3.59F3A%victor@jvknet.com>
From: Arturo Servin <arturo.servin@gmail.com>
Date: Thu, 24 Oct 2013 12:56:29 -0200
Message-ID: <CALo9H1YovqQqn8MYdBMEZ37Jqsc=TqG0v2HsbXDiFKeM=ovtRg@mail.gmail.com>
To: Victor Kuarsingh <victor@jvknet.com>
Content-Type: multipart/alternative; boundary=001a11c1b31ce8ef3204e97dd737
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, Ted Lemon <mellon@fugue.com>, "Ole Troan \(otroan\)" <otroan@cisco.com>, Dave Thaler <dthaler@microsoft.com>, "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" <draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org>
Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 24 Oct 2013 15:00:09 -0000

I think that neither RA or DHCP can serve as the only-solution to provide
dynamic configuration information in IPv6. There are use cases where one is
suitable and the other is not as some have point out.

What I think we need is a clear strategy of what we need to do regarding
those mechanisms and accept that we will need to support them both in the
stack.

Lorenzo's proposals seems to be a good start.

/as


On Thu, Oct 24, 2013 at 10:55 AM, Victor Kuarsingh <victor@jvknet.com>wrote;wrote:

>
>
> From: Lorenzo Colitti <lorenzo@google.com>
>
> >I see two possible ways out of this:
>
> >>1. Decide a clear split between what goes into RA and what goes into
> DHCPv6, and then stick to it. For example, we >>could say that
> configuration information that is required to obtain basic connectivity on
> a network must be available in >>RA so it can be dynamically updated and
> shares fate with routing, and that everything that's not strictly required
> for >>the host's connectivity can go into DHCPv6. I don't know if it will
> be possible to draw a line here. If operators insist that >>DHCPv6 by
> itself must be sufficient, then we have no choice but to duplicate
> information.
>
> [VK] Although this is theoretically possible, I am not if we can actually
> orchestrate this and keep it split indefinitely.  I think we will see
> requests/requirements on both sides which may drive (I.e. Like operators)
> functions into either protocol.
>
>
> >>2. Attempt to say that RAs and DHCPv6 are simply containers and propose
> a unified option format so we can have the >>same options in both of them.
> I know this was already proposed once and was shot down, but I wasn't
> around, so I >>don't know why. (CCing a few people who might know).
>
> [VK] This seems like an intriguing idea. Would this mean that every option
> must go into each container, or that there will be a common set of options
> which go into both, and perhaps exceptions go into one or the other? (On
> that latter part, I guess that line of thinking gets us back to where we
> are).
>
> Regards,
>
> Victor K
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>