Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.txt

From: Vízdal Aleš <[email-masked]>
Date: Fri, 1 Feb 2013 22:47:09 +0100

Hi,

thanks for the update. Please find some comments below.

3.1 Scenario 1: No Global Address on the UE

After the initial configuration using RS/RA the 3GPP network still may be 
sending the RAs as the 3GPP TS 29.061, 11.2.1.3.4 says that 

"MaxRtrAdvInterval shall have a default value of 21 600 s (6 h) and
MinRtrAdvInterval shall have a default value of 0,75 × MaxRtrAdvInterval 
i.e.16 200 s (4,5 h)." 

So, it shall be mentioned that the SLAAC feature shall be disabled on the 3GPP 
interface to avoid this interface to be self auto configured with a GUA resulting
in the same /64 bound to both 3GPP and LAN interfaces.

3.2 Scenario 2: Global Address Only Assigned to LAN

In case of Privacy Extensions will be enabled on the 3GPP interface, shall it
be mentioned that each address from a given prefix shall be moved or is
it obvious?

4. Security Considerations

Since Scenario 3 does not  allow for Privacy Extension to run the 3GPP interface, 
UEs that require this functionality must find an alternative method.

Given that the Privacy Extensions will be disabled on the 3GPP interface,
can we propose to use Privacy Extensions on LAN interface to fix the issue above?

Cheers,
Ales

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Tuesday, January 29, 2013 8:01 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the IPv6 Operations Working Group of the IETF.
> 
> 	Title           : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a
> LAN
> 	Author(s)       : Cameron Byrne
>                           Dan Drown
> 	Filename        : draft-ietf-v6ops-64share-01.txt
> 	Pages           : 8
> 	Date            : 2013-01-29
> 
> Abstract:
>    This document describes three methods for extending an IPv6 /64
>    prefix from a User Equipment 3GPP radio interface to a LAN.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-v6ops-64share-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 03 Feb 2013 17:07:35 +0100

Le 01/02/2013 22:47, Vízdal Aleš a écrit :
> After the initial configuration using RS/RA the 3GPP network still
> may be sending the RAs as the 3GPP TS 29.061, 11.2.1.3.4 says that
>
> MinRtrAdvInterval shall have a default value of 0,75 ×
> MaxRtrAdvInterval i.e.16 200 s (4,5 h)."
>
> So, it shall be mentioned that the SLAAC feature shall be disabled
> on the 3GPP interface to avoid this interface to be self auto
> configured with a GUA resulting in the same /64 bound to both 3GPP
> and LAN interfaces.

I agree with this suggestion.

In addition, this should be strengthened by the fact that once the wlan
interface is up and the forwarding is set, this becomes a Router.  As
far as I remember specifications, a Router does not do interpret the
received RAs (not for SLAAC nor for any other parameter interpretation,
like MTU) on any of its interfaces.

> In case of Privacy Extensions will be enabled on the 3GPP interface,
> shall it be mentioned that each address from a given prefix shall be
> moved or is it obvious?

I don't think it is obvious.  In our setting the privacy address is
there but we simply didn't think about moving it.

> Since Scenario 3 does not  allow for Privacy Extension to run the
> 3GPP interface, UEs that require this functionality must find an
> alternative method.
>
> Given that the Privacy Extensions will be disabled on the 3GPP
> interface, can we propose to use Privacy Extensions on LAN interface
> to fix the issue above?

Sounds as a good idea.  In this way one offers privacy for applications
running on a cellular-enabled Router which has extended the /64 beyond
its cellular interface.

I think it makes sense.

But I think it is also worth formulating this first in terms of a need
for Privacy - i.e. make sure that 64share does not eliminate Privacy.

Alex

>
> Cheers, Ales
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of internet-
>> [email-masked] Sent: Tuesday, January 29, 2013 8:01 PM To:
>> [email-masked] Cc: [email-masked] Subject: [v6ops] I-D
>> Action: draft-ietf-v6ops-64share-01.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the IPv6 Operations
>> Working Group of the IETF.
>>
>> Title           : Extending an IPv6 /64 Prefix from a 3GPP Mobile
>> Interface to a LAN Author(s)       : Cameron Byrne Dan Drown
>> Filename        : draft-ietf-v6ops-64share-01.txt Pages
>> : 8 Date            : 2013-01-29
>>
>> Abstract: This document describes three methods for extending an
>> IPv6 /64 prefix from a User Equipment 3GPP radio interface to a
>> LAN.
>>
>>
>> _______________________________________________ v6ops mailing list
>>  [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>