Re: [v6ops] draft-ietf-v6ops-64share WGLC

"cb.list6" <cb.list6@gmail.com> Thu, 19 September 2013 19:18 UTC

Return-Path: <cb.list6@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 9B66721F9635 for <v6ops@ietfa.amsl.com>; Thu, 19 Sep 2013 12:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.24
X-Spam-Level:
X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, 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 Hb5X5AjebocH for <v6ops@ietfa.amsl.com>; Thu, 19 Sep 2013 12:17:59 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BA94321F93BF for <v6ops@ietf.org>; Thu, 19 Sep 2013 12:17:58 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id m15so7456517wgh.5 for <v6ops@ietf.org>; Thu, 19 Sep 2013 12:17:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tUXdMi4ejFpXidpRDZ4VmROnN910C0hu/BK8b0vEhTw=; b=wUb0U6Jvs4V00k32njy3LGkb3TzDRegDeogKWMEMz6574BlrBBa3d87RWoIcGV6zlv zYwAn6YUF+GYzpbfO9OBgWbirr+k1/sdgVCSHSQdSYGTKxtYKoZMu5ilUl9R3H8EJzai OJYbDM0N4YCLohaVUD6aIYLkJnHJE0jrzTyzXgnczFlnQnBV9SXR1Go9p07T8aYHrtnI S4MvsuyWKy0qqmjzGN+pL5JepU2gFHkRJUyR87mlGhKzfZ3u/kNMU3v/jJ73j4I9xfBc XrTo7mSv1yHdDVF/aY0ta7WvdmLGwzkV6Vo7kz8DYevuJVBl2QgrKsdxeC5o3qPZ/Tdk 30rw==
MIME-Version: 1.0
X-Received: by 10.180.20.163 with SMTP id o3mr275730wie.1.1379618277802; Thu, 19 Sep 2013 12:17:57 -0700 (PDT)
Received: by 10.217.114.137 with HTTP; Thu, 19 Sep 2013 12:17:57 -0700 (PDT)
In-Reply-To: <AFAB9759B1DE4F4187483FC509B501990115CC3ACBF7@HE111490.emea1.cds.t-internal.com>
References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> <AFAB9759B1DE4F4187483FC509B501990115CC3ACBF7@HE111490.emea1.cds.t-internal.com>
Date: Thu, 19 Sep 2013 12:17:57 -0700
Message-ID: <CAD6AjGRE4uMfcTfdXEmXsHVTHazxKtALFjojSEYos=rrL+ma-A@mail.gmail.com>
From: "cb.list6" <cb.list6@gmail.com>
To: Holger Metschulat <holger.metschulat@telekom.de>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC
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, 19 Sep 2013 19:18:00 -0000

On Thu, Sep 19, 2013 at 11:40 AM,  <holger.metschulat@telekom.de> wrote:
> Hello all,
>
> I believe this needs to be looked at. DNS server addresses are sent from the network to the mobile host ("CE" in this scenario) by outband 3GPP signalling and need to be queried by the CE OS driver from the radio chip.
>
> In order to convey the DNS information to the clients attached via the LAN, the CE performing 64share needs to handle the DHCP solicits and answer on the network's behalf because simply forwarding the DHCP solicits will not work at all (the network won't answer them).
>

I agree that is required for a functioning product, but this is not a
product specification it is a connectivity sharing method only with a
very narrow scope and hopefully narrow window of use if and when
DHCP-PD comes to mobile.

If you would like to specify that behavior, it would be best to
reference this I-D as the connectivity model for WAN and RFC 6204 for
a product LAN or just reference that the product MUST support this I-D
as well as the relevant DHCPv6 and/or RDNSS

CB

> Holger
>
> -----Ursprüngliche Nachricht-----
> Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von Mark ZZZ Smith
> Gesendet: Mittwoch, 18. September 2013 23:59
> An: Teemu Savolainen; Tassos Chatzithomaoglou; v6ops@ietf.org
> Betreff: Re: [v6ops] draft-ietf-v6ops-64share WGLC
>
> +1
>
> This purpose here is to describe a work around to a limitation, not to specify how RAs/DHCPv6 are supposed to be generally used and what options are present in them. I don't think RA or DHCPv6 options that aren't essential or useful to this *specific* scenario should be mentioned at all. DNS in RAs is not special to or necessary to sharing a /64.
>
> Generally related to DHCPv6 option passing across a CE device (of which this would be one), I posted the following draft a while ago. I'd be interested in comments.
>
> "IPv6 CE Device DHCPv6 Option Transparency"
>
> http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00
>
>
>
>
>
>>________________________________
>> From: Teemu Savolainen <tsavo.stds@gmail.com>
>>To: Tassos Chatzithomaoglou <achatz@forthnetgroup.gr>; "v6ops@ietf.org"
>><v6ops@ietf.org>
>>Sent: Monday, 16 September 2013 4:12 PM
>>Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC
>>
>>
>>
>>IMHO it is better to keep this draft focused solely on address sharing, and not to go to other configuration topic or other possible problems.
>>
>>Btw most often, as of now, the "original" DNS server addresses are received via link layer signaling (see http://www.ietf.org/id/draft-ietf-v6ops-rfc3316bis-06.txt section 2.10), and thus, for example, may need to be added to "proxied" RA.
>>
>>Best regards,
>>
>>Teemu
>>
>>________________________________
>> From: Tassos Chatzithomaoglou
>>Sent: 15.9.2013 23:20
>>To: v6ops@ietf.org
>>Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC
>>
>>Just a quick question...
>>
>>I don't see any reference of DNS servers under 3.1, only MTU & Prefix.
>>Shouldn't there be a bullet showing that DNS info (UE address as DNS proxy, or original through-RA/DHCPv6 DNS servers) should also pass on the LAN link?
>>
>>--
>>Tassos
>>
>>Fred Baker wrote on 15/9/2013 21:00:
>>> This is to initiate a two week working group last call of
>>> http://tools.ietf.org/html/draft-ietf-v6ops-64share.  Please read it
>>> now. If you find nits (spelling errors, minor suggested wording
>>> changes, etc), comment to the authors; if you find greater issues,
>>> such as disagreeing with a statement or finding additional issues
>>> that need to be addressed, please post your comments to the list.
>>>
>>> We are looking specifically for comments on the importance of the
>>> document as well as its content. If you have read the document and
>>> believe it to be of operational utility, that is also an important
>>> comment to make.
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>>_______________________________________________
>>v6ops mailing list
>>v6ops@ietf.org
>>https://www.ietf.org/mailman/listinfo/v6ops
>>
>>_______________________________________________
>>v6ops mailing list
>>v6ops@ietf.org
>>https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops