Subject: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model?

From: 朱彥如 <[email-masked]>
Date: Wed, 19 Oct 2016 03:24:59 +0000

Hi:
   I am wondering if Unsolicited RA be sent in this model?

   Because a unique IPv6 prefix is assigned to each host, if multicast unsolicited RA is sent, it will send the prefix for host A to others (such as B, C, ….)
   If unicast unsolicited RA is sent, GW will has to remember each host’s multicast address….

Regards
Yann-Ju
ChungHwa Telecom. Co.

Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited.  Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Oct 2016 23:10:01 -0700

</chair>

Two important points:

First, the draft only asks that “multiple” addresses be available per host. This is in response to some enterprise environments that uSE DHCP to assign addresses and lock the host down to one (or maybe one “permanent” and one “temporary”). Multicast RA will happen in those environments, and means the same thing it means in a SLAAC environment except for the fact of not using SLAAC for the prefix.

The second model that is discussed but not nailed down in the draft is the assignment of a prefix, perhaps a /64, to a physical chassis to be distributed on a virtual “LAN” inside the host - to applications, containers, or whatever. In that case, the host OS operates as a router between the physical and virtual LANs, and the router that is its next hop (top-of-rack or whatever) learns the prefix allocated to the host by some other means - a routing protocol, SDN, or whatever. In such a case, there might be a prefix on the interconnect, but addresses in that context might be strictly local - no prefix necessary. I wouldn’t automatically assume that there is anything to RA about beyond the existence of the router.

> On Oct 18, 2016, at 8:24 PM, 朱彥如 <[email-masked]> wrote:
> 
> Hi:
> 本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
> Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information. _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 19 Oct 2016 08:21:30 +0200 (CEST)

>   If unicast unsolicited RA is sent, GW will has to remember each host’s multicast address….

Hi,

there is a draft proposed in 6man:

https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-00

It talks about some mechanisms needed that might be used in this context.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: 朱彥如 <[email-masked]>
Date: Wed, 19 Oct 2016 06:26:08 +0000

Sorry, I am a little confused.... Maybe，I didn't describe my problem correctly.

I give a summary of Section 4 ((IPv6 Unique Prefix Assignment) in this draft:
1. When a UE connects to the shared provider managed network, it sends a RS to learn the default gateway. 
2. The First Hop Provider Router will answer  using a unicast RA (Router Advertisement) to the UE/subscriber

According to above descriptions, the First Hop Provider Router should send "Unicast" Solicited RA (in reply to RS).

My questions are: 
In addition to this "Unicast" Solicited RA, will the First Hop Provider Router send "un-solicited" RA??
If the answer is yes, Is this periodic unsolicited RA Unicast or Multicast?
If it is Multicast, then this multicast RA will send the prefix for host A to others (such as B, C, ….)

Regards
Yann-Ju
   
-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2016 2:10 PM
To: 朱彥如
Cc: [email-masked]
Subject: [外部郵件] Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model?

</chair>

Two important points:

---

From: Erik Kline <[email-masked]>
Date: Wed, 19 Oct 2016 15:31:27 +0900

> If the answer is yes, Is this periodic unsolicited RA Unicast or Multicast?

It depends on whether or not you have link-layer isolation.  If you
have link-layer isolation between clients then the router than unicast
or multicast and RA with the client's PIO.

Without link-layer isolation the only two options are:

    [1] unicast RA with client's PIO

    [2] multicast RA without any PIOs

Clients receiving the latter should not automatically invalidate their
previously received PIOs--they should just honor the timers they last
received.  However, this approach may be straying into "different
clients behave differently" territory.

> _______________________________________________
> v6ops mailing list
> [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 19 Oct 2016 15:50:16 +0900

>     [1] unicast RA with client's PIO

By "unicast" do you mean L2 unicast, or IPv6 unicast to the link-local
address? IPv6 unicast requires that the link-local address never change,
and I'm not sure that's a valid assumption.

> clients behave differently" territory.

Any compliant client will not invalidate the prefix lifetime just because
the multicast RA doesn't have a PIO, due to RFC 4861 section 6.34:

   Hosts
   accept the union of all received information; the receipt of a Router
   Advertisement MUST NOT invalidate all information received in a
   previous advertisement or from another source. "

However, the PIOs *will* eventually time out and become deprecated (at
which point the client will prefer IPv4 and may even disconnect), and then
be removed. So for this to work the PIO lifetimes have to be longer than
the amount of time for which the network is willing to provide service to
the hosts.

I'm not sure it's a good idea to do prefix-per-host without network
isolation. In such an environment, hosts on the same network being able to
mount various link-layer attacks such as deny IPv6 address formation (by
causing DAD conflicts), exhaust neighbour cache entries, etc. The operator
might not expect this to be possible since the hosts have different
prefixes.

---

From: 朱彥如 <[email-masked]>
Date: Wed, 19 Oct 2016 06:50:16 +0000

I do not catch up with these new standards in development (draft-pioxfolks-6man-pio-exclusive-bit-00), and will take some time to undertand.
However, PIO extension to RA is still in development, do the existing clients support it?

As I know, Comcast Xfintiy Wifi seems to use "unique IPv6 prefix per host" and unicast Solicited RA.
I am curious about how they send periodic Un-Solicited RA? 
I don't think "RA with PIO" will be understood by the most existing clients. (Or, it really already be supported??)

Thanks
Yann-Ju

-----Original Message-----
From: Erik Kline [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2016 2:31 PM
To: 朱彥如
Cc: Fred Baker; [email-masked]
Subject: [外部郵件] Re: [v6ops] [外部郵件] Re: unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model?

On 19 October 2016 at 15:26, 朱彥如 <[email-masked]> wrote:
> 2. The First Hop Provider Router will answer  using a unicast RA 
> (Router Advertisement) to the UE/subscriber
>

It depends on whether or not you have link-layer isolation.  If you have link-layer isolation between clients then the router than unicast or multicast and RA with the client's PIO.

Clients receiving the latter should not automatically invalidate their previously received PIOs--they should just honor the timers they last received.  However, this approach may be straying into "different clients behave differently" territory.

>> Please be advised that this email message (including any attachments) 
>> contains confidential information and may be legally privileged. If 
>> you are not the intended recipient, please destroy this message and 
>> all attachments from your system and do not further collect, process, 
>> or use them. Chunghwa Telecom and all its subsidiaries and associated 
>> companies shall not be liable for the improper or incomplete 
>> transmission of the information contained in this email nor for any 
>> delay in its receipt or damage to your system. If you are the 
>> intended recipient, please protect the confidential and/or personal 
>> information contained in this email with due care. Any unauthorized 
>> use, disclosure or distribution of this message in whole or in part 
>> is strictly prohibited. Also, please self-inspect attachments and 
>> hyperlinks contained in this email to ensure the information security 
>> and to protect personal information. 

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件.如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited.  Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

---

From: 朱彥如 <[email-masked]>
Date: Wed, 19 Oct 2016 07:02:10 +0000

I think “unique prefix per host” has some benefits for ISP public WiFi operation, such as easy Billing or tracking (based on prefix, not the changing IPv6 prefix due to privacy extension)
Even not using “unique prefix per host”, link-layer attacks still exist…..

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Wednesday, October 19, 2016 2:50 PM
To: Erik Kline
Cc: 朱彥如; [email-masked]
Subject: [外部郵件] Re: [v6ops] [外部郵件] Re: unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model?

On Wed, Oct 19, 2016 at 3:31 PM, Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:
Without link-layer isolation the only two options are:

By "unicast" do you mean L2 unicast, or IPv6 unicast to the link-local address? IPv6 unicast requires that the link-local address never change, and I'm not sure that's a valid assumption.

Any compliant client will not invalidate the prefix lifetime just because the multicast RA doesn't have a PIO, due to RFC 4861 section 6.34:

   Hosts

However, the PIOs *will* eventually time out and become deprecated (at which point the client will prefer IPv4 and may even disconnect), and then be removed. So for this to work the PIO lifetimes have to be longer than the amount of time for which the network is willing to provide service to the hosts.

I'm not sure it's a good idea to do prefix-per-host without network isolation. In such an environment, hosts on the same network being able to mount various link-layer attacks such as deny IPv6 address formation (by causing DAD conflicts), exhaust neighbour cache entries, etc. The operator might not expect this to be possible since the hosts have different prefixes.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 19 Oct 2016 16:09:36 +0900

One major issue to consider is that if you have a unique prefix per host,
then isolation becomes much simpler and much more scalable.

Doing client isolation when different hosts are on the same prefix requires
ND snooping, DAD proxying, and keeping lots of state. Doing client
isolation when different hosts have different prefixes is much simpler:
basically just separate the subnets at layer 2 and most of the problems are
solved.

On Wed, Oct 19, 2016 at 4:02 PM, 朱彥如 <[email-masked]> wrote:

> I think “unique prefix per host” has some benefits for ISP public WiFi
> operation, such as easy Billing or tracking (based on prefix, not the
> changing IPv6 prefix due to privacy extension)
>
> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Wednesday, October 19, 2016 2:50 PM
> *To:* Erik Kline
> *Cc:* 朱彥如; [email-masked]
> *Subject:* [外部郵件] Re: [v6ops] [外部郵件] Re: unique-ipv6-prefix-per-host Will
> Unsolicited RA be sent in this model?
>
>
>
> *本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件.
> 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
> contains confidential information and may be legally privileged. If you are
> not the intended recipient, please destroy this message and all attachments
> from your system and do not further collect, process, or use them. Chunghwa
> Telecom and all its subsidiaries and associated companies shall not be
> liable for the improper or incomplete transmission of the information
> contained in this email nor for any delay in its receipt or damage to your
> system. If you are the intended recipient, please protect the confidential
> and/or personal information contained in this email with due care. Any
> unauthorized use, disclosure or distribution of this message in whole or in
> part is strictly prohibited. Also, please self-inspect attachments and
> hyperlinks contained in this email to ensure the information security and
> to protect personal information.*
>

---

From: 朱彥如 <[email-masked]>
Date: Wed, 19 Oct 2016 07:54:23 +0000

Can anybody give me the possible method to achieve link layer isolation?
Because in public wifi environment, clients connect to network dynamically, we just can not configure vlan for each client in advance.

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Wednesday, October 19, 2016 3:10 PM
To: 朱彥如
Cc: Erik Kline; [email-masked]
Subject: [外部郵件] Re: [外部郵件] Re: [v6ops] [外部郵件] Re: unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model?

One major issue to consider is that if you have a unique prefix per host, then isolation becomes much simpler and much more scalable.

Doing client isolation when different hosts are on the same prefix requires ND snooping, DAD proxying, and keeping lots of state. Doing client isolation when different hosts have different prefixes is much simpler: basically just separate the subnets at layer 2 and most of the problems are solved.

On Wed, Oct 19, 2016 at 4:02 PM, 朱彥如 <[email-masked]<mailto:[email-masked]>> wrote:
I think “unique prefix per host” has some benefits for ISP public WiFi operation, such as easy Billing or tracking (based on prefix, not the changing IPv6 prefix due to privacy extension)
Even not using “unique prefix per host”, link-layer attacks still exist…..

From: Lorenzo Colitti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, October 19, 2016 2:50 PM
To: Erik Kline
Cc: 朱彥如; [email-masked]<mailto:[email-masked]>
Subject: [外部郵件] Re: [v6ops] [外部郵件] Re: unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model?

   Hosts

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 19 Oct 2016 17:00:06 +0900

I would expect the AP controllers will need to support this as a feature.

John, Gunter: are you using commercial hardware in your deployment, or is
it custom-built?

On Wed, Oct 19, 2016 at 4:54 PM, 朱彥如 <[email-masked]> wrote:

> Because in public wifi environment, clients connect to network
> dynamically, we just can not configure vlan for each client in advance.
>
>
>
>
>
> *Sent:* Wednesday, October 19, 2016 3:10 PM
> *To:* 朱彥如
> *Cc:* Erik Kline; [email-masked]
> *Subject:* [外部郵件] Re: [外部郵件] Re: [v6ops] [外部郵件] Re:
> unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model?
>
>
>
> Doing client isolation when different hosts are on the same prefix
> requires ND snooping, DAD proxying, and keeping lots of state. Doing client

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 19 Oct 2016 11:14:24 +0000

Commercially available hardware.  The APs are not really where most of the work happens, it’s the wireless aggregate router.  Don’t get me still has to have some level of IPv6 support, ie not dropping IPv6 multicast (think ICMPv6).

Is the question here how to prevent hosts from interacting with other hosts when IPv6 is enabled?

John
+1-484-962-0060

From: v6ops <[email-masked]> on behalf of Lorenzo Colitti <[email-masked]>
Date: Wednesday, October 19, 2016 at 04:00
To: John Brzozowski <[email-masked]>, "Gunter Van de Velde (gvandeve)" <[email-masked]>
Cc: v6ops <[email-masked]>
Subject: Re: [v6ops] [外部郵件] Re: [外部郵件] Re: [外部郵件] Re: unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model?

John, Gunter: are you using commercial hardware in your deployment, or is it custom-built?

On Wed, Oct 19, 2016 at 4:54 PM, 朱彥如 <[email-masked]<mailto:[email-masked]>> wrote:
Can anybody give me the possible method to achieve link layer isolation?
Because in public wifi environment, clients connect to network dynamically, we just can not configure vlan for each client in advance.

From: Lorenzo Colitti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, October 19, 2016 3:10 PM
To: 朱彥如
Cc: Erik Kline; [email-masked]<mailto:[email-masked]>
Subject: [外部郵件] Re: [外部郵件] Re: [v6ops] [外部郵件] Re: unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model?

   Hosts

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 19 Oct 2016 11:17:57 +0000

Part of what we have started to roll out ensures that clients (hosts, UEs) are allocated unique IPv6 prefixes and that they do not reside in the same IPv6 prefix.  Client isolation can also be done at the link layer in the APs, nothing to do with IP or layer 3.  Allocation of unique prefixes per host helps however, technically hosts are still reachable unless hosts protect themselves or the first hop layer 3 router has controls in place to prevent router between unique prefixes allocated to UEs.

John
+1-484-962-0060

From: v6ops <[email-masked]> on behalf of Lorenzo Colitti <[email-masked]>
Date: Wednesday, October 19, 2016 at 03:09
To: 朱彥如 <[email-masked]>
Cc: v6ops <[email-masked]>
Subject: Re: [v6ops] [外部郵件] Re: [外部郵件] Re: unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model?

   Hosts

---

From: 朱彥如 <[email-masked]>
Date: Wed, 19 Oct 2016 14:28:42 +0000

As I know, client isolation done in the APs is split horizon for BUM??

My original question is :
Under the unique prefix per host host with split horizon for BUM, Will WLAN-GW still send un-solicited periodic RA? (If yes, multicast or unicast...)

A new question:
If user isolation is implemented in Commercially available hardware (wireless aggregate router), is it the controller in your model or the WLAN-GW, or the router behind WLAN-GW??
What is the really function for user isolation?

I am really interested in these topic, because we are planning to provide IPv6 PWLAN service in the near future

________________________________
寄件者: Brzozowski, John [[email-masked]]
已傳送: Wednesday, 19 October, 2016 19:17
收件者: Lorenzo Colitti; 朱彥如
副本: [email-masked]
主旨: [外部郵件] Re: [v6ops] [外部郵件] Re: [外部郵件] Re: unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model?

John
+1-484-962-0060

   Hosts

---

From: Hemant Singh <[email-masked]>
Date: Wed, 19 Oct 2016 10:33:15 -0400

With respect to Containers, please note, the Container community has copied
Container IPv4 behavior to IPv6.  For security, so that Container ports
could accidentally be advertised to the whole world via a global IPv4
address, IPv4 Containers use a private IPv4 with NAT44.  IPv6 has done the
same with ULA.  Thus a global IPv6 address may not be used by a Container.
Why not also have apps and whatever else also use a ULA?

See this URL for the IPv6 Container implementation.  The URL includes some
discussion related to NAT.

https://github.com/robbertkl/docker-ipv6nat

Regards,

Hemant

On Wed, Oct 19, 2016 at 2:10 AM, Fred Baker <[email-masked]>
wrote:

The second model that is discussed but not nailed down in the draft is the
> assignment of a prefix, perhaps a /64, to a physical chassis to be
> distributed on a virtual “LAN” inside the host - to applications,
> containers, or whatever. In that case, the host OS operates as a router
> between the physical and virtual LANs, and the router that is its next hop
> (top-of-rack or whatever) learns the prefix allocated to the host by some
> other means - a routing protocol, SDN, or whatever. In such a case, there
> might be a prefix on the interconnect, but addresses in that context might
> be strictly local - no prefix necessary. I wouldn’t automatically assume
> that there is anything to RA about beyond the existence of the router.
>
>

---

From: Hemant Singh <[email-masked]>
Date: Wed, 19 Oct 2016 10:42:00 -0400

Note, IPv6 has "UM" traffic, not BUM, since Broadcast does not exist in
IPv6.  When an RA with no PIO is used, hosts send non-link-local traffic to
the default router.  Thus the hosts do not issue any address resolution
multicast NS messages.  This off-link model has (a) removed multicast NS
messages from the link, and (b) isolated user traffic as well.  See some
general rules in RFC 5942.   Additionally, if the host has issued an RS,
the IPv6 ND default router does know this host and can unicast the RA to
this host.

Since IPv6 ND is involved, whichever node in the network supports the IPv6
ND default router, is also a good node to isolate users.   I will let John
reply as well.

Regards,

Hemant

On Wed, Oct 19, 2016 at 10:28 AM, 朱彥如 <[email-masked]> wrote:

> Under the unique prefix per host host with split horizon for BUM, Will
> WLAN-GW still send un-solicited periodic RA? (If yes, multicast or
> unicast...)
>
> A new question:
> If user isolation is implemented in Commercially available hardware
> (wireless aggregate router), is it the controller in your model or the
> WLAN-GW, or the router behind WLAN-GW??
> ------------------------------
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Oct 2016 17:02:11 +0900

On Wed, Oct 19, 2016 at 11:33 PM, Hemant Singh <[email-masked]> wrote:

> With respect to Containers, please note, the Container community has
> copied Container IPv4 behavior to IPv6.  For security, so that Container
> ports could accidentally be advertised to the whole world via a global IPv4

https://tools.ietf.org/html/rfc7934#section-5

> https://github.com/robbertkl/docker-ipv6nat

AIUI that project started because lots of things didn't work with global
IPv6 addresses and they didn't have a good method to assign IPv6 addresses
to containers. That doesn't mean it was the right thing to do, and it
definitely doesn't mean that other designs should follow that approach.

---

From: Hemant Singh <[email-masked]>
Date: Thu, 20 Oct 2016 11:20:27 -0400

The IPv6 Container code duplicated what the IPv4 Container code does.  As I
said in the past, the IPv4 Container use a private IPv4 address (including
why) and thus the IPv6 code also uses a ULA.  The ULA packets cannot go out
to the Internet and stay within the local network.   Thus, I think using a
ULA by the IPv6 Docker Container is not open to debate.

On a different note, before the IPv4 /8 address pools were all used up, at
each IETF, especially in the plenary session, folks asked "why does Skype
not support IPv6".  We should collect a list of such broken IPv6 nodes such
as the IPv6 Container, and other software and hardware that does not
support IPv6 and put the list at a wiki.  Maybe such a wiki already exists
related to v6ops.    Then we can, as a team, fix the software and hardware,
including prioritizing what gets fixed first.  Recently, a video streamer
which has existed since 1999 and even supported till today did not support
IPv6.  I took that public-domain code and made it work for IPv6 in about
one week.   I am going to put the code in the public domain after more
testing is done.

Cheers,

Hemant

---

From: Mark Smith <[email-masked]>
Date: Mon, 24 Oct 2016 06:15:53 +1100

On 21 October 2016 at 02:20, Hemant Singh <[email-masked]> wrote:
> to the Internet and stay within the local network.

In theory. Packets leak via default routes all of the time. (I
appreciate what you're saying, however lets not pretend just using
private addresses prevents unwanted packet leaks to the Internet)

>  Thus, I think using a

I really think we should put some effort into convincing them that
ULAs and NAT66 are not the way to achieve the security they want. This
viewpoint also shows a lack of some fundamentals about IPv6 - such
that it is possible to have both public and private addresses
concurrently.

Once IPv6 application developers have to assume the possibility of the
presence of NAT, every application will be burdened with either NAT
traversal code or will be forced to adopt a client-server
architecture, even when a peer-to-peer application architecture that
IPv6 (without NAT) can facilitate would be far better.

I've assumed the whole point of containers is to run one
service/application per container because the container overhead is so
minimal. I'd think that means that firewalling of containers is almost
binary - either remote access to the container is available or it
isn't. In other words, a container won't hold a mix of public and
private applications (if there is any inter-application communication
within a container, it takes place over ::1), so firewalling should be
much simpler.

I think this is an example of applying pure IPv4 mentality to IPv6. In
recent times I've started to think that it would have been better to
create the demand for IPv6 deployment not be promoting it to network
operators, but rather, the promoting its benefits to the people who
create the capability demands of the network - the networked
application developers.

> as the IPv6 Container, and other software and hardware that does not support
> IPv6 and put the list at a wiki.  Maybe such a wiki already exists related
> to v6ops.    Then we can, as a team, fix the software and hardware,
> IPv6.  I took that public-domain code and made it work for IPv6 in about one
> week.   I am going to put the code in the public domain after more testing
> is done.
>
> Cheers,
>
> Hemant
>
>

Regards,
Mark.

---

From: Hemant Singh <[email-masked]>
Date: Mon, 24 Oct 2016 18:03:55 -0400

On Sun, Oct 23, 2016 at 3:15 PM, Mark Smith <[email-masked]> wrote:

> A bare-metal machine is running 100 Containers.  Each Container has a
global IPv6 address.  Doesn't one now have to provision a firewall for
these 100 IPv6 source addresses?  It more provisioning vs. adding NAT
support to apps are the the two extremes.   Sure, we should run this
Container behavior by IETF app groups.  Operators who run large data
centers are also welcome to chime in.   In some instances between a large
company intranet and extranet to its external vendors, NAT44 is used and
thus a NAT66 draft was actually authored by Fred Baker.

Regards,

Hemant

---

From: Fred Baker <[email-masked]>
Date: Mon, 24 Oct 2016 17:24:19 -0700

Sent from my iPad

> On Oct 24, 2016, at 3:03 PM, Hemant Singh <[email-masked]> wrote:
> 
>    In some instances between a large company intranet and extranet to its external vendors, NAT44 is used and thus a NAT66 draft was actually authored by Fred Baker.  

If you're going to invoke my name, you might consider getting your facts straight. Read RFC 6296, including the Security Considerations, before continuing.

---

From: Hemant Singh <[email-masked]>
Date: Mon, 24 Oct 2016 21:24:10 -0400

Fred,

I had heard the comments during a presentation at an IETF about intra vs.
extra net and NAT66 as a use case, especially Cisco as a company.  My
apologies, if I incorrectly said anything..  Appreciate the RFC reference.

Hemant

On Mon, Oct 24, 2016 at 8:24 PM, Fred Baker <[email-masked]>
wrote:

> >    In some instances between a large company intranet and extranet to
> its external vendors, NAT44 is used and thus a NAT66 draft was actually
> authored by Fred Baker.
>
> If you're going to invoke my name, you might consider getting your facts
> straight. Read RFC 6296, including the Security Considerations, before
> continuing.

---

From: Mark Smith <[email-masked]>
Date: Tue, 25 Oct 2016 13:14:10 +1100

global IPv6 address.  Doesn't one now have to provision a firewall for
these 100 IPv6 source addresses?  It more provisioning vs. adding NAT
support to apps are the the two extremes.

Containers a light weight virtual machines, and VMs are virtualised
physical machines.

How are and have people been securing 100s/1000s of physical machines
running apps? It's not a new problem caused by containers.

Google and Facebook are providing large scale services over IPv6, I very
much doubt they're using ULAs with giant stateful NAT66 boxes in front of
all of them.

>   Sure, we should run this Container behavior by IETF app groups.
Operators who run large data centers are also welcome to chime in.   In
some instances between a large company intranet and extranet to its
external vendors, NAT44 is used and thus a NAT66 draft was actually
authored by Fred Baker.

If you're referring to Network Prefix Translation, it doesn't do or work
the way you think it does.

You also might want to have a look at this:

"The Trouble with NAT"
https://www.slideshare.net/mobile/MarkSmith214/ausnog-2016-the-trouble-with-nat

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Oct 2016 16:37:46 +1300

Hemant,
On 25/10/2016 14:24, Hemant Singh wrote:
>> its external vendors, NAT44 is used 

To be clear, that mode (first raised in the IETF by Bob Moskowitz, iirc,
and the original inspiration for HIP) was only ever needed because of
IPv4 address exhaustion and the fact that companies and their business
partners were all using Net 10 internally. It's actually a nightmare, too,
because translating Net 10 to Net 10 is... ugly. Which 10.1.1.1 did
you actually mean? Yours or theirs?

>>and thus a NAT66 draft was actually
>> authored by Fred Baker.

Indeed it wasn't, because it would be an utterly stupid thing to do
for IPv6 - you might also look at https://tools.ietf.org/html/rfc4864.

The fact that some open source NAT66 code exists doesn't make it
a good idea.

Regards
    Brian

---

From: Hemant Singh <[email-masked]>
Date: Tue, 25 Oct 2016 08:42:21 -0400

Sorry, I didn't recall Fred's doc was prefix and not address related -
since Fred sent us the RFC, I realized it.  Never mind NAT66,  If the only
support that Docker Container supports is NAT66 with ULA, it is clear, no
one is using this Container.

It's apples vs. oranges discussing apps vs. Containers.  The app uses the
IP address of the machine or the VM running on the machine.   The machine,
the VM, and the app communicate to any other node in the data center or
even to an external node to the data center.  In contrast, the Containers
generate/acquire an IP address and, by default, do not communicate to any
other node in the data center and thus have to be provisioning
differently.  The scale of Containers to provision for an IP/IPv6 address,
networking, and firewall, is another challenge because it's one thing to
provision one million bare-metal machines and another to provision 100
million Containers.

Regards,

Hemant

---

From: Mark Smith <[email-masked]>
Date: Wed, 26 Oct 2016 06:28:19 +1100

On 25 October 2016 at 23:42, Hemant Singh <[email-masked]> wrote:
> Sorry, I didn't recall Fred's doc was prefix and not address related - since
> Fred sent us the RFC, I realized it.  Never mind NAT66,  If the only support
> that Docker Container supports is NAT66 with ULA, it is clear, no one is
> using this Container.
>
> It's apples vs. oranges discussing apps vs. Containers.  The app uses the IP
> address of the machine or the VM running on the machine.

With IPv6 it doesn't need to. It would be quite possible to give a
container its own IPv6 address, and I think that is the assumption
that is commonly being made here (because containers are nothing more
than with light weight VMs, with the only significant differences been
faster startup times and the ability run many more on the same
physical machine).

It would even be possible for each application component within a
container to have its own IPv6 address.

So much more is possible and conceivable because of IPv6's so much
larger address space than IPv4's.

>   The machine, the
> VM, and the app communicate to any other node in the data center or even to
> an external node to the data center.  In contrast, the Containers
> other node in the data center and thus have to be provisioning differently.
> The scale of Containers to provision for an IP/IPv6 address, networking, and
> firewall, is another challenge because it's one thing to provision one
> million bare-metal machines and another to provision 100 million Containers.
>

We solve these problems the same way we commonly solve them - scalably
using a divide-and-conquer approach - slice the problem up into
smaller versions and then solve the multiple instances of the same
smaller problem.

Delegating prefixes to physical or virtual machines for use with
containers is the exact same technique that has been used to scale the
Internet's routing system. Delegation of an aggregate, and then
sub-division downstream of the aggregate, hidden from the upstream.

Regards,
Mark.

>> > Operators who run large data centers are also welcome to chime in.   In some
>> > instances between a large company intranet and extranet to its external
>> > vendors, NAT44 is used and thus a NAT66 draft was actually authored by Fred
>> > Baker.
>> >
>>

---

From: Mark Smith <[email-masked]>
Date: Wed, 26 Oct 2016 06:38:04 +1100

> you actually mean? Yours or theirs?

It certainly is. One of the lessons I learnt from working with two
NATs facing each other and duplicated address spaces behind them is to
place more significant value on the global uniqueness of addresses.
For operating and troubleshooting a network, it is immensely useful to
be in a position to say "that packet could have only come from or be
going to host X", regardless of where host X is.

In IPv4 we had no choice but to consume globally routable addresses to
achieve this global uniqueness, even if we didn't intend or need host
X to have global connectivity.

In IPv6, we have two choices. If host X needs to have both a globally
unique address and have global reachability, give it a GUA. If only a
globally unique address is required, give it a (properly formed) ULA.
(Or combinations of the two for different use cases.)

Regards,
Mark.

<snip>