Subject: AD Evaluation : draft-ietf-6man-ra-pref64-06

From: Suresh Krishnan <[email-masked]>
Date: Sat, 2 Nov 2019 03:49:38 +0000

Hi authors,
  I found this draft generally well written and easy to read but I would like a couple of things fixed in it before I send it off to IETF Last call.

* Abstract

OLD:
This document specifies a Router Advertisement option to communicate
NAT64 prefixes to hosts.

NEW:
This document specifies a Neighbor Discovery option to be used in Router
Advertisements to communicate NAT64 prefixes to hosts.

Also make the same change in the Introduction as well.

* Section 2

Maybe worth adding a reference to DoH (RFC8484) here in addition to RFC7858.

* Section 4

Please use a documentation prefix, say 192.0.2.0/24, instead of the RFC1918 address currently used in the example.

* Section 5

The use of the term “lifetime” or “life time” to denote both the intended period of use and the value of the Lifetime field which is one-eighth of the intended value is a bit confusing. Can you deconflict this by calling the field “ShortLifetime" or something similar?

* Section 7

PvD: Define before use and add and a reference to [draft-ietf-intarea-provisioning-domains]

* Section 9

"Providing all
   configuration in Router Advertisements increases security by ensuring
   that no other protocols can be abused by malicious attackers to
   provide hosts with invalid configuration.”

This is not strictly true, right? e.g. Someone can still use PCP to override the Pref64 information from the RA. Suggest rewording to something like this

"Providing all configuration in Router Advertisements reduces the attack surface to be targeted by malicious attackers to provide hosts with invalid configuration as compared to distributing the configuration through multiple different mechanisms that need to be secured independently.”

Thanks
Suresh

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 2 Nov 2019 13:02:55 +0900

On Sat, 2 Nov 2019, 12:49 Suresh Krishnan, <[email-masked]> wrote:

> Please use a documentation prefix, say 192.0.2.0/24, instead of the
> RFC1918 address currently used in the example.
>

Are you sure this would be an improvement? The example would become less
realistic because 1) 192.0.2.0/24 is a /24 and subnetting a /24 is unusual,
and 2) it's seems like a reasonable thing to do to route private space to a
different NAT.

Is there a larger documentation prefix than 192.0.2.0/24?

* Section 7
>
> PvD: Define before use and add and a reference to
> [draft-ietf-intarea-provisioning-domains]
>

A better reference might be RFC7556.

"Providing all
> This is not strictly true, right? e.g. Someone can still use PCP to
> override the Pref64 information from the RA. Suggest rewording to something
> like this

Well, only if nodes implemented the PCP method, which they don't... but
yes, this is true in theory.

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 2 Nov 2019 04:11:47 +0000

Hi Lorenzo,
  Thanks for the quick response!

On Nov 2, 2019, at 12:02 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, 2 Nov 2019, 12:49 Suresh Krishnan, <[email-masked]<mailto:[email-masked]>> wrote:
Please use a documentation prefix, say 192.0.2.0/24<http://192.0.2.0/24>, instead of the RFC1918 address currently used in the example.

Are you sure this would be an improvement?

Yes, I think so :-). Addresses in examples end up being used in real life far too often. I am not going to insist on this change and I leave it to your discretion.

The example would become less realistic because 1) 192.0.2.0/24<http://192.0.2.0/24> is a /24 and subnetting a /24 is unusual, and 2) it's seems like a reasonable thing to do to route private space to a different NAT.

Is there a larger documentation prefix than 192.0.2.0/24<http://192.0.2.0/24>?

Unfortunately not. 128.66.0.0/16 was used a long time ago for this purpose but was never officially sanctioned.

* Section 7

Works for me.

"Providing all

Well, only if nodes implemented the PCP method, which they don't... but yes, this is true in theory.

Given that the PCP method is a IETF defined mechanism and this document does put it on the top of the pecking order, I think it is better to use something like the alternate formulation that I suggested.

Regards
Suresh

---

From: Ted Lemon <[email-masked]>
Date: Sat, 2 Nov 2019 05:27:16 -0400

> Given that the PCP method is a IETF defined mechanism and this document does put it on the top of the pecking order, I think it is better to use something like the alternate formulation that I sugg…

If it is actually bad for nodes to implement PCP, it would be good if this were discussed.  I hadn’t heard this before, and in fact consider it a problem that routers implement the horribly complex uPnP protocol instead of PCP.

I realize this is an inopportune time given that you are finishing a document, but if you have time can you expand on this a tiny bit?

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 2 Nov 2019 23:51:51 +0900

On Sat, Nov 2, 2019 at 6:27 PM Ted Lemon <[email-masked]> wrote:

> <#m_6103543545046494038_m_-2734443725323270902_>
> Given that the PCP method is a IETF defined mechanism and this document
> does put it on the top of the pecking order, I think it is better to use
> something like the alternate formulation that I suggested.
>
>
> If it is actually bad for nodes to implement PCP, it would be good if this
> were discussed.  I hadn’t heard this before, and in fact consider it a
> problem that routers implement the horribly complex uPnP protocol instead
> of PCP.
>
> I realize this is an inopportune time given that you are finishing a
> document, but if you have time can you expand on this a tiny bit?
>

I didn't say discovering the pref64 via PCP is bad, I said I don't think
hosts implement it. Note: what I am referring to is specifically only
discovering the pref64 via PCP. ISTM that whether hosts do or do not
implement other parts of PCP, and whether they should or not, is out of
scope for this document. What did you want to expand on specifically?

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 2 Nov 2019 23:57:01 +0900

On Sat, Nov 2, 2019 at 1:11 PM Suresh Krishnan <[email-masked]> wrote:

> Yes, I think so :-). Addresses in examples end up being used in real life
> far too often. I am not going to insist on this change and I leave it to
> your discretion.
>

Either way is fine by me. I have a mild preference to keep as is. Jen?

> something like the alternate formulation that I suggested.

Your alternative formulation works for me. To be pedantic, though: the text
says "providing all configuration in Router Advertisements". If the network
is providing "all" configuration via RA, then it's not using PCP, right?

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Nov 2019 18:01:18 -0400

> and 2) it's seems like a reasonable thing to do to route private space
    > to a different NAT.

I agree with you.

    > Is there a larger documentation prefix than 192.0.2.0/24?

I wish that there was.
Maybe we could carve out of class E space as a /20 of documentation space.
I'd also like to have three or four additional IPv6 documentation prefixes,
plus some documentation space from ULA-R and ULA-C.

I'd like the IPv6 documentation prefixes to have a pretty high Hamming
Distance from each other to maximize the visual distinction.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 2 Nov 2019 23:02:49 +0000

Hi Michael/Lorenzo,

> On Nov 2, 2019, at 6:01 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Me too. I also think a larger prefix could be useful. Similarly a block that would differentiate it as an example of private space to be used.

> Maybe we could carve out of class E space as a /20 of documentation space.

Sounds like a plan. If you write something up, I would be willing to AD sponsor something like this. The biggest issue with repurposing E space was that it would hit a lot of bogon filters. In this case that is a desirable feature.

> plus some documentation space from ULA-R and ULA-C.

What is ULA-R? Did you mean ULA-L? If so, it would be a pain to reserve something now since we also need to update RFC4193 to make sure that the Random “Global ID”s will not collide with the reserved prefixes. If ULA-C does take off, this would be a good idea to do something like this.

> Distance from each other to maximize the visual distinction.

We have a /32 for this. Plenty of ways to be visually distinct including some of the common ones I have used :-)

2001:db8:abba::/48
2001:db8:beef::/48
2001:db8:cafe::/48
2001:db8:dead::/48
2001:db8:face::/48
2001:db8:c001::/48

Cheers
Suresh

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Nov 2019 12:18:27 -0500

> Me too. I also think a larger prefix could be useful. Similarly a block
    > that would differentiate it as an example of private space to be used.

    > Sounds like a plan. If you write something up, I would be willing to AD
    > sponsor something like this. The biggest issue with repurposing E space
    > was that it would hit a lot of bogon filters. In this case that is a
    > desirable feature.

Okay, I will write something if there is further support.
Should it update or replace RFC5737?

    > What is ULA-R? Did you mean ULA-L? If so, it would be a pain to reserve
    > something now since we also need to update RFC4193 to make sure that
    > the Random “Global ID”s will not collide with the reserved prefixes. If
    > ULA-C does take off, this would be a good idea to do something like
    > this.

I guess L=1 is why you call it ULA-L. I have known it as ULA-Random.
We are both talking about RFC4193 though.  So such a document would need to
update RFC4193.

    > We have a /32 for this. Plenty of ways to be visually distinct
    > including some of the common ones I have used :-)

    > 2001:db8:c001::/48

I'm not sure that I agree.
I don't see why we need to be so stingy about Documentation Prefixes in IPv6.
Using part of 3ffe::/16 would appeal to me.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 4 Nov 2019 08:32:39 +1300

> Suresh Krishnan <[email-masked]> wrote:
...
> We are both talking about RFC4193 though.  So such a document would need to

I think this is a bad and pointless idea. Pointless because it is 100% OK
to use any RFC4193 prefix as an example, since by definition it will never
be used on the Internet, and the chance of collision on a given ULA site
is 1 in 2**40 (and who cares anyway?). Bad because it means that millions
of existing boxes that can generate ULA prefixes would be non-conformant
and, seriously, is any vendor going to update date their firmware for this?

Regards,
   Brian

---

From: Job Snijders <[email-masked]>
Date: Sun, 3 Nov 2019 20:55:23 +0000

On Sat, Nov 02, 2019 at 11:02:49PM +0000, Suresh Krishnan wrote:
> >>> Please use a documentation prefix, say 192.0.2.0/24, instead of
> >>> the RFC1918 address currently used in the example.
> > 
> >> Are you sure this would be an improvement? The example would become
> >> less realistic because 1) 192.0.2.0/24 is a /24 and subnetting a
> >> /24 is unusual, and 2) it's seems like a reasonable thing to do to
> >> route private space to a different NAT.
> > 
> > I agree with you.

Absolutely.

> Me too. I also think a larger prefix could be useful. Similarly a
> block that would differentiate it as an example of private space to be
> used.
> 
> Sounds like a plan. If you write something up, I would be willing to
> AD sponsor something like this. The biggest issue with repurposing E
> space was that it would hit a lot of bogon filters. In this case that
> is a desirable feature.

This is music to my ears.

In draft-ietf-sidrops-rpkimaxlen we are running into the issue that
there isn't something larger than a /24 that isn't also private space.

Kind regards,

Job

---

From: Jen Linkova <[email-masked]>
Date: Mon, 4 Nov 2019 08:57:56 +1100

Hi Suresh,

Thanks a lot for your review!

> Please use a documentation prefix, say 192.0.2.0/24, instead of the RFC1918 address currently used in the example.

Actually I'd agree with Lorenzo here..IMHO 10.0.0.0/8 case describes a
realistic scenario while 192.0.2/024 would look a bit artificial.  If
the text was saying 'if the operator would like to route all private
address space  through NAT64 device A' instead of
'if the operator would like to route 10.0.0.0/8 through NAT64 device
A' we would not be using the example address space here, would we?

Would it be better if that sentence says:
''For example if the operator would like to route RFC1918 address
space, e.g. 10.0.0.0/8  through NAT64 device A'?

> The use of the term “lifetime” or “life time” to denote both the intended period of use and the value of the Lifetime field which is one-eighth of the intended value is a bit confusing. Can you dec…

How about 'Lifetime Multiplier'?

-- 
SY, Jen Linkova aka Furry

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Nov 2019 09:34:09 +1100

> and, seriously, is any vendor going to update date their firmware for this?

I redacted my ULA in examples in a presentation I did recently. That made
it impossible to type in and for somebody to duplicate.

If the goal is ensure people can't try to use these example addresses on
real networks, then perhaps using invalid addresses in the document with a
note that they're examples and invalid on purpose is a better idea.

For example, using non-hexidecimal letters, with a note about them being
substitutes for 'a' through 'f'.

E.g.

2001:db8:xxxx:yyyy::zzz1

> Regards,
>    Brian
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 4 Nov 2019 11:47:05 +1300

On 04-Nov-19 11:34, Mark Smith wrote:
> 
> 
> On Mon, 4 Nov 2019, 06:33 Brian E Carpenter, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > Suresh Krishnan <[email-masked] <mailto:[email-masked]>> wrote:
>     ...
>     >     >> I'd also like to have three or four additional IPv6 documentation prefixes,
>     >     >> plus some documentation space from ULA-R and ULA-C.
>     >
>     >     > What is ULA-R? Did you mean ULA-L? If so, it would be a pain to reserve
>     >     > something now since we also need to update RFC4193 to make sure that
>     >     > the Random “Global ID”s will not collide with the reserved prefixes. If
>     >     > ULA-C does take off, this would be a good idea to do something like
>     >     > this.
>     >
> I redacted my ULA in examples in a presentation I did recently. That made it impossible to type in and for somebody to duplicate.
> 
> If the goal is ensure people can't try to use these example addresses on real networks, then perhaps using invalid addresses in the document with a note that they're examples and invalid on purpose is a better idea.
> 
> For example, using non-hexidecimal letters, with a note about them being substitutes for 'a' through 'f'.
> 
> E.g.
> 
> 2001:db8:xxxx:yyyy::zzz1
> 

Yes, that makes sense, and could be applied to link-local and RFC1918
addresses too. It's a much less fiddly solution.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Nov 2019 19:21:10 -0500

> and, seriously, is any vendor going to update date their firmware for this?

So, each time a document uses a ULA-Random in an example that calls for ULAs,
someone will ask why they didn't use 2001:db8::/32.

The other plus is places that ask for a ULA to be typed in can recognize the
Documentation prefix, and suggest that maybe that's not what they wanted to do.

{I don't expect any ULA generator to get updated, as you said, 1/2**40.
But, on the other hand, how many ULA generators are out there?}

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 4 Nov 2019 01:05:19 +0000

> On Nov 3, 2019, at 5:47 PM, Brian E Carpenter <[email-masked]> wrote:
> 

+1. Agree that this could be a good solution, I think the idea is to use not very realistic prefixes that people can just cut and paste into real configurations.

Thanks
Suresh

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Nov 2019 12:08:52 +1100

> But, on the other hand, how many ULA generators are out there?}

How ever many CPE there are that follow RFC 7084, "Basic Requirements
for IPv6 Customer Edge Routers" or its ancestor RFC 6204.

That includes all CPE running OpenWRT, the commercial CPE at my
sister's house which she received from her residential ISP without my
involvement (advertising a correctly generated ULA /48 on its LAN
interface, even though IPv6 isn't enabled on the WAN), and one or two
IPv6 CPE I looked at in 2010.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 4 Nov 2019 02:49:25 +0000

> On Nov 3, 2019, at 2:32 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Agree with you Brian. That is why I called out the collision issue above.

Regards
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 4 Nov 2019 02:56:48 +0000

Hi Michael,

> On Nov 3, 2019, at 12:18 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Either would work for me (with a slight preference for replacing). Write up the draft and ask for a slot in intarea if possible to gauge community interest in this. I can take it from there.

> Using part of 3ffe::/16 would appeal to me.

In case I was not clear above, I was just stating that I didn't *personally* see a need for an additional prefix block. If there is a community backed proposal to do so, I would consider myself in the rough and move aside :-).

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 4 Nov 2019 03:01:37 +0000

Hi Job,

> On Nov 3, 2019, at 3:55 PM, Job Snijders <[email-masked]> wrote:
> 

Cool. Michael said he would write something up on this. Let’s chat in Singapore if you are around.

> there isn't something larger than a /24 that isn't also private space.

I read the draft and I completely understand why you need this. 

Regards
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 4 Nov 2019 03:08:26 +0000

Hi Jen,

> On Nov 3, 2019, at 4:57 PM, Jen Linkova <[email-masked]> wrote:
> 
> Hi Suresh,
> 
> space, e.g. 10.0.0.0/8  through NAT64 device A’?

I think this formulation is a bit better but I liked Mark Smith’s idea on my Additional Documentation Prefixes subthread (Thanks Mark!!) of using x’s instead of the 0’s here to obfuscate. Then it will be clear to readers that it is private space while not being directly usable. i.e. do something like

"For example if the operator would like to route RFC1918 address
space, e.g. 10.x.x.x/8  through NAT64 device A"

> How about 'Lifetime Multiplier’?

I would have assumed that the multiplier in this case would actually be 8. How about “Scaled Lifetime”? Does that work?

Thanks
Suresh

---

From: Jen Linkova <[email-masked]>
Date: Mon, 4 Nov 2019 14:38:31 +1100

> space, e.g. 10.x.x.x/8  through NAT64 device A"

If '/8' is used then there is no difference between '10.0.0.0/8' and
'10.x.x.x/8' and 'x.x.x' would only confuse a reader, IMHO.
Please note that we are not trying to pick up any arbitrary prefix but
instead discussing a practical example on 'how to treat NAT64 traffic
for RFC1918 address space differently from the Internet traffic. Also,
using '10.0.0.0/8' is easy as it translated to 'a00' in
2001:db8:a:b::a00:0/104 which, I believe, easy to comprehend.

If you think that the explicit mention of RFC1918 makes the
formulation better, how about this:
"For example if the operator is using 10.0.0.0/8 private address space
internally and would like to route RFC1918 addresses through NAT64
device A’

> I would have assumed that the multiplier in this case would actually be 8. How about “Scaled Lifetime”? Does that work?

Heh, I was thinking the same and actually renamed it to 'Lifetime
Multiplicand' but after discussing it with Lorenzo the idea was
discarded.
Scaled Lifetime would do, thanks!

---

From: Jen Linkova <[email-masked]>
Date: Mon, 4 Nov 2019 14:44:30 +1100

> In case I was not clear above, I was just stating that I didn't *personally* see a need for an additional prefix block. If there is a community backed proposal to do so, I would consider myself in…

I could recall it's been discussed before and discarded:
https://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-01

---

From: Leo Vegoda <[email-masked]>
Date: Thu, 7 Nov 2019 19:53:21 +0000

On 11/3/19, 1:58 PM, "ipv6 on behalf of Jen Linkova" <[email-masked] on behalf of [email-masked]> wrote:

[...]

>     Actually I'd agree with Lorenzo here..IMHO 10.0.0.0/8 case describes a

It might be worth noting that RFC 5737 includes this statement in the introduction:

"Documentation also makes use of the ranges reserved in [RFC1918]."

Kind regards,

Leo