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

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Sun, 20 January 2013 21:00 UTC

Return-Path: <rajiva@cisco.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 D4D3C21F8795 for <v6ops@ietfa.amsl.com>; Sun, 20 Jan 2013 13:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level:
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mMLOE8THKXv for <v6ops@ietfa.amsl.com>; Sun, 20 Jan 2013 13:00:23 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E673521F8722 for <v6ops@ietf.org>; Sun, 20 Jan 2013 13:00:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5002; q=dns/txt; s=iport; t=1358715623; x=1359925223; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=E9gUKj56sxyABu59OwwxpECKkro74VnleDK33iFz/+U=; b=WE4fjtzfopRD8KiqPwgi+1YfQq7wAtgiBia+zhYA3nB5xQtvKXPa/eUI VyhzRq6zPFd9gWJ0FJK29NHCDfnmg0lkbW2LlXIlTMEIIM7YZ+UjEEIMH ATFI2X6OH7mW8y5uohXS4EZgNDzjO+Y/hdHOPGh1gCJ+VGPhpi6amWCus I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFALZa/FCtJV2d/2dsb2JhbABEvjcWc4IeAQEBAwE6PwUHBAIBCA4DBAEBAQoUCQchERQJCAIEAQ0FCId/AwkGDLIXDYhmjAltg2JhA5Q2BIJuihuFEoJ1giQ
X-IronPort-AV: E=Sophos;i="4.84,501,1355097600"; d="scan'208";a="165021574"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 20 Jan 2013 21:00:18 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0KL0Ira032640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jan 2013 21:00:18 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Sun, 20 Jan 2013 15:00:18 -0600
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Cameron Byrne <cb.list6@gmail.com>, Mark Smith <markzzzsmith@yahoo.com.au>
Thread-Topic: [v6ops] draft-ietf-v6ops-64share
Thread-Index: AQHN9rAv6ksovCUlQUORbevJhQ4wYphSepiAgABZ6gD//9xtQA==
Date: Sun, 20 Jan 2013 21:00:17 +0000
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B114D78ED@xmb-rcd-x06.cisco.com>
References: <CAD6AjGSEOva1RzDXJqmstFk=13JnPUSWM9rQ3PmXCXPQQwcBDQ@mail.gmail.com> <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> <CAD6AjGSfJHTwL-TM+U68h6SOtcid5JD_0ZJpFufyG3P-bOYtsQ@mail.gmail.com>
In-Reply-To: <CAD6AjGSfJHTwL-TM+U68h6SOtcid5JD_0ZJpFufyG3P-bOYtsQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.83.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: v6ops v6ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-64share
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: Sun, 20 Jan 2013 21:00:23 -0000

Hi Cameron,

It wasn't crystal clear that LAN side and WAN side interfaces were using the same IPv6 address. So, Mark's suggested text will make it clear.

You might also want to mention 'no DAD on WAN interface (i.e. 3GPP interface)' before mentioning DAD on LAN interface. 

Wrt assigning the same IP address on two different (IP-enabled) interfaces, I can only think of 'IP unnumbered' model and it might be worth mentioning.  Else, what could it be? What's implemented in iOS?


> Is there an ietf doc on what a translational bridge is? We considered

I don't think so, but there are number of RFCs that refer to IEEE specification for bridging. Check out the L2VPN WG.

Lastly, I would suggest to prepend 3GPP before UE below (to differentiate from UEs attaching on the LAN):

> > "The UE checks to make sure the 3GPP interfaces is active and has


Cheers,
Rajiv

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Cameron Byrne
> Sent: Sunday, January 20, 2013 11:53 AM
> To: Mark Smith
> Cc: v6ops v6ops WG
> Subject: Re: [v6ops] draft-ietf-v6ops-64share
> 
> Mark,
> 
> Sent from ipv6-only Android
> On Jan 20, 2013 3:31 AM, "Mark Smith" <markzzzsmith@yahoo.com.au>
> wrote:
> >
> > Hi,
> >
> >
> > >________________________________
> > > From: Cameron Byrne <cb.list6@gmail.com>
> > >To: v6ops@ietf.org
> > >Sent: Sunday, 20 January 2013 12:23 PM
> > >Subject: [v6ops] draft-ietf-v6ops-64share
> > >
> > >
> > >Hi,
> > >I posted this update as a WG draft
> > >http://tools.ietf.org/html/draft-ietf-v6ops-64share-00
> > >Please take the time to review this update and share your feedback.  I
> hoping that a clearly defined scope, clear need for this work,  as well
> running code will make it easy to advance. I am now aware of 3
> implementations that approximately use this method (ios6, an LTE mifi
> router, and Dan Drown's Android submission)
> >
> > Regarding this text,
> >
> >  9.  Since the address 2001:db8:ac10:f002:1234:4567:0:9/128 is the
> >        only instance of the assigned /64 on the 3GPP interface, there is
> >        no chance of an address conflict on that interface.  On the LAN
> >        interface, there is no chance of address conflict since the
> >
> >
> >
> > Byrne                    Expires June 17, 2013                  [Page 4]
> >
> > V6OPS Working Group   draft-ietf-v6ops-64share-00      December 14, 2012
> >
> >
> >        address is defended using Duplicate Address Detection (DAD).
> >
> > I'd suggest adding something like "address is defended using Duplicate
> Address Detection (DAD), as the LAN interface is also assigned the address
> in use on the 3GPP interface."
> >
> > I struggled a bit with working out what was going on until it became clear
> that the 3GPP and LAN interfaces are using the same global unicast address.
> >
> 
> The DAD procedure on the LAN is only scoped for the LAN. For the 3gpp link,
> it is the fact that only 1 off-link address is architecturally permitted by 3gpp
> that ensures no collision.
> 
> Did I parse your concern correctly?
> 
> > I also think it would be better to be clearer about the type of IPv6 address
> and also cover that their may be multiple IPv6 addresses, such as privacy
> addresses on the 3GPP/LAN interface. For example, in 3. Method for Sharing
> the 3GPP Interface /64 to the Tethered LAN,
> >
> > "The UE checks to make sure the 3GPP interfaces is active and has
> >        an IPv6 address.  If the interface does not have an IPv6 address,
> >        an attempt will be made to acquire one, or else the procedure
> >        will terminate."
> >
> > Strictly, the 3GPP interface always has an IPv6 address because it always
> has a link local address, so the above would be better if it clarified that the
> type of address to check for is a global IPv6 address.
> >
> 
> Ack. I will change it to "globally scoped address"
> 
> > I'll have to do some digging, however I'm wondering if the sockets API
> might have an assumption that an individual IPv6 address is only assigned to
> a single interface.
> >
> > Actually, reviewing the IPv6 Addressing Model in RFC4291, it says, "An IPv6
> unicast address refers to a single interface."
> >
> > Was a translational bridge model considered? That is, the 3GPP and LAN
> interfaces are part of a bridge instance, and a single bridge virtual layer 2/3
> interface is assigned the UE's global unicast address within the /64, with a
> /64 prefix length. Enabling or disabling tethering would be a simple matter
> of administratively enabling/disabling the LAN interface.
> >
> 
> Is there an ietf doc on what a translational bridge is? We considered
> ndproxy but that method was deemed unfit due to insufficient loop
> prevention.
> 
> CB
> 
> > Regards,
> > Mark.
>