Subject: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis

From: Jen Linkova <[email-masked]>
Date: Tue, 5 Nov 2013 18:50:32 +0100

Section 4.2. says that
"

So when using ULAs in a network, the administrators should clearly
   set the scope of the ULAs and configure ACLs on relevant border
   routers to block them out of the scope. And if internal DNS are
   enabled, the administrators might also need to use internal-only DNS
   names for ULAs.
"
I believe it should that that the administrator MUST configure egress
ACLs on borders routers and MUST ensure that their DNS servers do not
include ULAs in any responses to external clients.

-- 
SY, Jen Linkova aka Furry

---

From: Arturo Servin <[email-masked]>
Date: Tue, 5 Nov 2013 16:16:42 -0200

Blocking according to DNS content would be something like Deep Packet
Inspection, isn't it?

Do we want to go there?

/as

On Tue, Nov 5, 2013 at 3:50 PM, Jen Linkova <[email-masked]> wrote:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Nov 2013 07:25:43 +1300

> Blocking according to DNS content would be something like Deep Packet

No, but that's not what he means. He means split DNS, where
the internal DNS server includes records that are not present
in the external DNS server. That, like it or not, is standard
practice today in many enterprise networks.

   Brian

> ------------------------------------------------------------------------
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 5 Nov 2013 18:45:42 +0000

Hi, Brian

Thanks for your explanation, that is what the draft means.
It might needs re-wording to make it clearer.

Regards,
Bing

________________________________________
From: [email-masked] [[email-masked]] on behalf of Brian E Carpenter [[email-masked]]
Sent: Tuesday, November 05, 2013 10:25
To: Arturo Servin
Cc: [email-masked]
Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis

   Brian

---

From: Arturo Servin <[email-masked]>
Date: Tue, 5 Nov 2013 16:46:52 -0200

Then we need more text because that is not clear enough.

Also, talking about DNS, another advise would be to to have reverse
delegations on internal DNS to avoid leaking queries.

.as

---

From: Jen Linkova <[email-masked]>
Date: Tue, 5 Nov 2013 19:59:21 +0100

> Blocking according to DNS content would be something like Deep Packet

There are various ways to achieve it but I think the standard way is
to use split DNS. Anyway I don't think that the document in question
must dictate how to prevent DNS leakage (although having some
recommendation would be nice).

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 5 Nov 2013 19:28:32 +0000

Hi, Jen

I got your comments. I'll consider to revise accordingly. Many thanks

Regards,
Bing

________________________________________
From: [email-masked] [[email-masked]] on behalf of Jen Linkova [[email-masked]]
Sent: Tuesday, November 05, 2013 09:50
To: [email-masked]
Subject: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis

Section 4.2. says that
"

---

From: George Michaelson <[email-masked]>
Date: Tue, 5 Nov 2013 11:29:43 -0800

I tend to SHOULD. you can do what you like, but the consequence of not
doing a local delegation is information leakage. There is no compelling MUST

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Nov 2013 06:58:18 +1100

In message <[email-masked]>
> doing a local delegation is information leakage. There is no compelling MUST

And if you have random address selection you along with random
prefix selection you have a 2^114 birthday paradox space.  I'll
assume the subnet are not random.

You have a 2^40 birthday paradox space of a getting sub optimal
address selection order.  i.e. you will try the ULA before GUA.

> --047d7b33da0a02fb4e04ea730e22
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">I tend to SHOULD. you can do what you like, but the conseq=
> uence of not doing a local delegation is information leakage. There is no c=
> ompelling MUST</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_=
> quote">
> On Tue, Nov 5, 2013 at 11:28 AM, Liubing (Leo) <span dir=3D"ltr">&lt;<a hre=
> f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=
> m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
> n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Hi, Jen<br>
> <br>
> I got your comments. I&#39;ll consider to revise accordingly. Many thanks<b=
> r>
> <br>
> Regards,<br>
> Bing<br>
> <br>
> ________________________________________<br>
> From: <a href=3D"mailto:[email-masked]">[email-masked]</a> =
> [<a href=3D"mailto:[email-masked]">[email-masked]</a>] on b=
> ehalf of Jen Linkova [<a href=3D"mailto:[email-masked]">[email-masked]=
> m</a>]<br>
> 
> Sent: Tuesday, November 05, 2013 09:50<br>
> To: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> Subject: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis<br>
> <div class=3D"HOEnZb"><div class=3D"h5"><br>
> Section 4.2. says that<br>
> &quot;<br>
> <br>
> So when using ULAs in a network, the administrators should clearly<br>
> =A0 =A0set the scope of the ULAs and configure ACLs on relevant border<br>
> =A0 =A0routers to block them out of the scope. And if internal DNS are<br>
> =A0 =A0enabled, the administrators might also need to use internal-only DNS=
> <br>
> =A0 =A0names for ULAs.<br>
> &quot;<br>
> I believe it should that that the administrator MUST configure egress<br>
> ACLs on borders routers and MUST ensure that their DNS servers do not<br>
> include ULAs in any responses to external clients.<br>
> <br>
> <br>
> <br>
> <br>
> --<br>
> SY, Jen Linkova aka Furry<br>
> _______________________________________________<br>
> v6ops mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" target=3D"_blank">h=
> ttps://www.ietf.org/mailman/listinfo/v6ops</a><br>
> _______________________________________________<br>
> v6ops mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" target=3D"_blank">h=
> ttps://www.ietf.org/mailman/listinfo/v6ops</a><br>
> </div></div></blockquote></div><br></div>
> 
> --047d7b33da0a02fb4e04ea730e22--
> 
> --===============5663455589702191862==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============5663455589702191862==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jen Linkova <[email-masked]>
Date: Wed, 6 Nov 2013 02:55:27 +0100

On Tue, Nov 5, 2013 at 8:29 PM, George Michaelson <[email-masked]> wrote:
> I tend to SHOULD. you can do what you like, but the consequence of not doing
> a local delegation is information leakage. There is no compelling MUST

Thanks for your comment, George!
After thinking about it for a while and checking RFC4193 I stand
corrected: it should be 'SHOULD' in both cases.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 6 Nov 2013 03:16:47 +0100

> I got your comments. I'll consider to revise accordingly. Many thanks

Few more comments if you don't mind:

1) Section 3.1. Isolated network
"

- Prefix generation: Randomly generated according to the
      algorithms defined in [RFC4193] or literally assigned by human.
      Normally, it is recommended to following the standard way to
      automatically generate the prefixes; if there are some specific
      reasons that need to be assigned by human, the administrators must
      carefully plan the prefixes to avoid collision."

As Erik pointed out this Monday, "recommended" violates RFC4193.
In addition, I'm not sure why you are mentioning prefix generation in
"Isolated network' section only while it is applicable for all
scenarios.
Maybe it should be moved to the section 4 "General Guidelines"

2) 3.3. IPv4 Co-existence consideration
Looks like it is being discussed in another thread already - I think
you might mention 'sending ICMPv6 message back' and 'not having
default route' as options to prevent the issue.

3) 4. General Guidelines of using ULA

It would be great to emphasize the importance of randomness and of
having L bit set so fd00 prefix will be used, not fc00::
Probably (as you mentioning DNS and ACL) it might make sense to refer
to Section 4 of RFC4193 which contains some guidelines as well.

Question: you do not mention VPN usage at all. Such use case is
described in RFC4193 but do you think it might be useful to mention it
at least?
===
One typo:
"2.3. Independent address space

   ULA provides an internal address independence capability in IPv6ULA
   can be used for internal communications without having any permanent
   or only intermittent Internet connectivity."

s/IPv6ULA/IPv6. ULA/

---

From: joel jaeggli <[email-masked]>
Date: Tue, 12 Nov 2013 09:41:22 -0800

On Nov 5, 2013, at 10:16 AM, Arturo Servin <[email-masked]> wrote:

> 
> Blocking according to DNS content would be something like Deep Packet Inspection, isn't it?

implementing split horizons on your nameservers is a fairly straight-forward exercise that doesn’t involve middle-boxes looking at packets…

likewise separating internal authoritative zone resolution from external ones is well understood and widely deployed in ipv4, afterall I have practical applications for working forward and reverse for the RFC-1918 space in my datacenters. I have no need, nor is it benificial for me to expose those zones/servers to queries from the outside.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 12 Nov 2013 19:41:29 +0000

> practice today in many enterprise networks.

</chair>

I'm told that it goes beyond that. There are at least three "directions" in the split:
   - inside, where internal-only names are advertised, might use an internal-only prefix, and even "outside" names might have different servers and different addresses.
   - outside, where internal-only names are not advertised
   - partner, which is "outside" plus some names made accessible to the partner, and may imply some form of b2b routing as well.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 13 Nov 2013 01:55:19 +0000

Hi, Fred

> I'm told that it goes beyond that. There are at least three "directions" in the
[Bing] Did you mean you are told from some real deployment, or told from the ULA draft?

>    - inside, where internal-only names are advertised, might use an
> internal-only prefix, and even "outside" names might have different servers
> and different addresses.
>    - partner, which is "outside" plus some names made accessible to the
> partner, and may imply some form of b2b routing as well.
[Bing] Say if ULAs are used for b2b private routing, in the "partner" case, does it means the b2b ULAs are stored in the outside DNS, so that the partners could get the ULAs through public DNS, and access to the ULAs through private routing?

Best Regards,
Bing

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 13 Nov 2013 11:32:36 +0000

> [Bing] Did you mean you are told from some real deployment, or told from the ULA draft?

I am on the board of a company that produces a product that is used in these configurations. One of the engineers told me it is a requirement his customers present him with. Today, that is generally IPv4, not IPv6, so I can't comment on ULAs, only extrapolate. I was commenting on the DNS configuration.

> [Bing] Say if ULAs are used for b2b private routing, in the "partner" case, does it means the b2b ULAs are stored in the outside DNS, so that the partners could get the ULAs through public DNS, and…

In the particular configuration, as I understand what the engineer told me, "inside", "outside", and in the "partner" case, the identity of the partner, are attributes in the underlying database. The software looks at the request, determines what data should be included in the response, and includes it.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 14 Nov 2013 08:18:15 +0000

Hi Fred,

Thanks for your detailed explain. It is very useful information.
I'll consider to include it in the next version.

Best regards,
Bing

> -----Original Message-----
> From: Fred Baker (fred) [mailto:[email-masked]]
> Sent: Wednesday, November 13, 2013 7:33 PM
> To: Liubing (Leo)
> Cc: Brian E Carpenter; [email-masked]
> >> I'm told that it goes beyond that. There are at least three
> >> "directions" in the
> >> split:
> I am on the board of a company that produces a product that is used in these
> configurations. One of the engineers told me it is a requirement his
> customers present him with. Today, that is generally IPv4, not IPv6, so I can't
> comment on ULAs, only extrapolate. I was commenting on the DNS
> configuration.
> 
> >> internal-only prefix, and even "outside" names might have different
> >> servers and different addresses.
> >>   - partner, which is "outside" plus some names made accessible to
> >> the partner, and may imply some form of b2b routing as well.
> > [Bing] Say if ULAs are used for b2b private routing, in the "partner" case,
> does it means the b2b ULAs are stored in the outside DNS, so that the
> partners could get the ULAs through public DNS, and access to the ULAs
> through private routing?
> 
> In the particular configuration, as I understand what the engineer told me,
> "inside", "outside", and in the "partner" case, the identity of the partner, are
> attributes in the underlying database. The software looks at the request,
> determines what data should be included in the response, and includes it.