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

From: [email-masked]
Date: Fri, 08 Feb 2013 16:31:38 -0800

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-02.txt
	Pages           : 8
	Date            : 2013-02-08

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-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Mon, 11 Feb 2013 13:55:16 +0100

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Samstag, 9. Februar 2013 01:32
An: [email-masked]
Cc: [email-masked]
Betreff: [v6ops] I-D Action: draft-ietf-v6ops-64share-02.txt

>	Title           : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN

Hi all,

could the following be considered:

- The UE in this case will have to behave like a router, meaning, at least two independent link-local addresses, no propagation of ND packets from WAN to (W)LAN and vice versa, etc.
- What happens when the WAN link drops, gets reestablished, and thus a new global prefix is assigned to the WAN link? Should the old prefix be advertised with a "zero" preferred lifetime together with the new prefix? Otherwise, the connected devices may not put the "old" prefix into the deprecated state.
- Should it be added how to convey the DNS resolver addresses to the attached hosts? On the 3GPP radio interface, they are retrieved from the PCO-IEs in the 3GPP signalling, but on the LAN, usually stateless DHCPv6 (RFC3646) or RA extensions (RFC6106) are being used.

Regards,
Holger

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Feb 2013 14:37:39 +0100

Le 11/02/2013 13:55, [email-masked] a écrit :
> -----Ursprüngliche Nachricht----- Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von
> [email-masked] Gesendet: Samstag, 9. Februar 2013 01:32 An:
> [email-masked] Cc: [email-masked] Betreff: [v6ops] I-D Action:
> draft-ietf-v6ops-64share-02.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.
>>
> - The UE in this case will have to behave like a router, meaning, at
>  least two independent link-local addresses, no propagation of ND
> packets from WAN to (W)LAN and vice versa, etc.

I agree.  The UE will act like a router.  And there will be at least two
independent ll addresses.  And ND packets must not be propagated.

In addition, this could be a place where it should be mentioned that if
the Gateway performs a NS for an address prefixed by the assigned /64,
the method described in this document (extend the /64 to the LAN) will
not work.

(otherwise mention it elsewhere).

In section 2, ND Proxy is mentioned.

> - What happens when the WAN link drops, gets reestablished, and thus
>  a new global prefix is assigned to the WAN link? Should the old
> prefix be advertised with a "zero" preferred lifetime together with
> the new prefix? Otherwise, the connected devices may not put the
> "old" prefix into the deprecated state.

I agree, when the WAN link drops, the UE should gracefully notify its
Clients that that prefix is no longer valid.

I guess it should be 'zero' preferred lifetime, with the old prefix, but
not the new prefix.  No?

> - Should it be added how to convey the DNS resolver addresses to the
>  attached hosts? On the 3GPP radio interface, they are retrieved from
>  the PCO-IEs in the 3GPP signalling, but on the LAN, usually
> stateless DHCPv6 (RFC3646) or RA extensions (RFC6106) are being
> used.

I agree there is a need to offer the DNS resolver from UE to the
Clients on LAN.  And that could be done with stateless DHCPv6, full
DHCPv6, or RA extensions - any of these 3 means.  I think there is not a
fourth.

There may even be possibility that UE runs DHCP Relay and the Clients on
LAN obtain the address of the DNS resolver straight from the DNS Server
in the infrastructure. (this may exist).

Alex

>
> Regards, Holger
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 11 Feb 2013 09:44:12 -0800

Holger,

> - The UE in this case will have to behave like a router, meaning, at least two independent link-local addresses, no propagation of ND packets from WAN to (W)LAN and vice versa, etc.

Yes, i believe the existing text makes that clear.  Do you believe
that is not clear?

> - What happens when the WAN link drops, gets reestablished, and thus a new global prefix is assigned to the WAN link? Should the old prefix be advertised with a "zero" preferred lifetime together w…

http://tools.ietf.org/html/draft-ietf-v6ops-64share-02#section-3.0

The existing text states "The LAN interface RA configuration must be tightly
   coupled with the 3GPP interface state.  If the 3GPP interface goes
   down or changes the IPv6 prefix, that state should be reflected in
   the LAN IPv6 configuration. "

I believe this covers what you are talking about without going into
the mechanics of how it is achieved.  For this informational document,
i would like to avoid details that are so specific.

> - Should it be added how to convey the DNS resolver addresses to the attached hosts? On the 3GPP radio interface, they are retrieved from the PCO-IEs in the 3GPP signalling, but on the LAN, usually…

I would also like to avoid this detail.  This topic is not germane to
how to share a prefix.  Including this detail makes it start to look
too much like a CPE specification.

CB

> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops