Subject: [v6ops] draft-pref64folks-6man-ra-pref64

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Oct 2018 14:45:52 +0000

Folks,

Each week between now and IETF 103, we will review and discuss one draft.

This week, please review and comment on draft-pref64folks-6man-ra-pref64

                                         Fred and Ron

---

From: 神明達哉 <[email-masked]>
Date: Mon, 15 Oct 2018 11:37:58 -0700

At Mon, 15 Oct 2018 14:45:52 +0000,

> This week, please review and comment on draft-pref64folks-6man-ra-pref64

I've read draft-pref64folks-6man-ra-pref64-02.  I don't have a strong
opinion on the proposal itself.  I have some minor comments on the
draft:

- Section 1: it would be more reader friendly if it expands "PvD" on
  its first use.

- In section 2 (or somewhere else like in the introduction) I think
  it's fair to point out that the RA approach has a drawback of
  configuring local routers of each end subnet (where ordinary clients
  reside).  It's unlike the advertisement of on-link/addrconf prefix
  for which the router should inherently know and be configured with
  anyway, so it looks to me to be a tradeoff between the router
  configuration overhead and the advantages described in this section.

  Similarly, we might want to note that this case in Section 5 should
  be (very?) atypical even if not forbidden:

   o  The pref64 option presents in a single RA more than once;

- Section 3

   For simplicity, this option only supports a NAT64 prefix length of 96
   bits, as this is by the most common configuration used by hosts.

  I have no problem with this restriction, but just saying "for
  simplicity" sounds a bit awkward as it also mentions the case of
  other prefix lengths and suggests other ways for such cases.  That's
  awkward to me since it's not difficult at all to support multiple
  different prefix lengths: just add another field to the option.  I
  guess one (major?) background rationale is the desire to keep the
  option length a multiple of 8 octets without padding.  I think
  that's worth mentioning.

- Section 3: these two don't read very consistently:

   This option may appear more than once in a Router Advertisement.
[...]
   This option specifies exactly one NAT64 prefix for all IPv4
   destinations.

  If it intends to specify *exactly one* prefix, what's the point of
  having more than one options (unless these options include exactly
  the same prefix, which also makes no sense).  I guess this is rather
  an editorial matter than a protocol problem - perhaps in this
  context we just don't have to say the "may appear more than once"
  sentence.

--
JINMEI, Tatuya

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 16 Oct 2018 08:47:32 +0200 (CEST)

> This week, please review and comment on draft-pref64folks-6man-ra-pref64

I read through the draft and support this work.

My only question is if all the text regarding PvDs etc really is needed? 
There is nothing special about this option, and the PvD documents already 
say the same thing as this document?

I don't oppose the text to be there, I'm just asking if it's strictly 
needed. I prefer drafts to be "short and sweet".

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jen Linkova <[email-masked]>
Date: Tue, 16 Oct 2018 21:05:09 +1100

Hi Mikael,

> say the same thing as this document?

That text was added in response to a comment made in 6man@ re: multihomed hosts.
You are right, there is nothing special about that option, it's just
another PvD-specific configuration option.
The reason to mention PvD is  be specific in describing corner cases.
The multi-homing scenario, when a host might receive multiple Pref64,
is one of such corner cases. IMHO it would be desirable to define the
host behavior and limitations of the proposed solution.

-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Tue, 16 Oct 2018 21:28:37 +1100

Jinmei-san,

Thanks a lot for your feedback.
Comments inline.

> - Section 1: it would be more reader friendly if it expands "PvD" on

Good point. I'll update the Terminology section.

>   configuration overhead and the advantages described in this section.

Well...Some vendors still require the prefix to be explicitly
configured under router-advertisement section to be included in PIOs
(just configuring /64 on the interface is not enough) so SLAAC does
require some explicit configuration anyway (and RDNSS and timers etc).
On the other hand, some vendor allow the configuration to be inherited
so in real life it will be one-line config to enable this option on
multiple interfaces...So, to be honest, I do not see much difference
between this option and any other SLAAC parameter...

>    o  The pref64 option presents in a single RA more than once;

It would be necessary for renumbering from one pref64 to another.
The old pref64 needs to be advertised with zero Lifetime, while the
new pref64 would have non-zero lifetime.

>   option length a multiple of 8 octets without padding.  I think

It's also configuration simplicity. But I see your point. We do try to
keep the option length to minimum,
to avoid increasing RA size. I'll try to rephrase this sentence to
make it more clear.

>    This option specifies exactly one NAT64 prefix for all IPv4

Sorry, I'm not sure I understand why. For example, a PIO contains
exactly one prefix. However Prefix Information Option may appear more
than once in a Router Advertisement.
The same here.

>   context we just don't have to say the "may appear more than once"

See the renumbering example above.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 16 Oct 2018 13:12:39 +0200 (CEST)

> host behavior and limitations of the proposed solution.

Right. Well, since I do want PvDs to work I don't think it hurts to 
mention it in documents like this. Just as long as we make sure we don't 
define anything new regarding that in any other document unintentionally.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 17 Oct 2018 11:22:43 -0700

At Tue, 16 Oct 2018 21:28:37 +1100,

> between this option and any other SLAAC parameter...

I'm afraid we're talking about different issues...maybe I wasn't clear
enough in the above comment, so let me rephrase it: assume if you have
100 leaf subnets, each of which has an RA-advertising router.  If you
want to deploy draft-pref64folks-6man-ra-pref64, you'll need to
configure those 100 routers separately; if the prefix is changed,
you'll need to update the config on these 100 routers.  On the other
hand, if you use a DNS-based approach (RFC7050) you'll only have to
configure/update the DNS(64) server (there may be multiple instances
of such server and you may have to configure each of them by hand, but
I assume the number of such instances is generally much smaller than
the number of leaf subnets).

This is different from other SLAAC parameters such as PIO, since the
information is different for different subnets and each router needs
to be configured separately anyway.

To be clear, I'm not making this comment to say that ra-pref64 is
inferior to existing ways.  I just thought there's some tradeoff
between different approaches and it's fair to explain both pros and
cons.

> new pref64 would have non-zero lifetime.

Ah, okay.  Perhaps that was just my bad reading, but the intent wasn't
clear to me from the draft's context.  In fact, it looks like the
other two bullets talk about the case of multiple usable prefixes
(right?)  Also, if I understand it correctly, "the recommendations
given in Section 3 of [RFC7050]" also discusses the case of multiple
usable prefixes:

   When multiple Pref64 were discovered via RA Pref64 Option [...],
   host behaviour with regards to synthesizing IPv6 addresses from IPv4
   addresses SHOULD follow the recommendations given in Section 3 of
   [RFC7050], limited to the NAT64 prefixes that have non-zero
   lifetime..

Only the above one bullet should mean the renumbering case since the
pref64 option should only support at most one usable prefix.  And then
the above paragraph still looks awkward: since "this option specifies
exactly one NAT64 prefix for all IPv4 destinations" (from Section 3)
I'd expect we only have at most one prefix that has non-zero
lifetime.  And then there's no point of applying the above
"recommendation" since it's "limited to the NAT64 prefixes that have
non-zero lifetime" (btw there's a redundant period here).

Perhaps I'm still misunderstanding something fundamental, but I
personally see some need for editorial clarification.

> See the renumbering example above.

See above.  Now I see how these two can coexist, but at least to me
it's not so obvious for fresh readers just from this text.  More
explanation to clarify the intent would help.

--
JINMEI, Tatuya

---

From: Fred Baker <[email-masked]>
Date: Wed, 17 Oct 2018 12:29:11 -0700

I'm not sure we disagree on your point. However, there is also the issue of shadowing services. For example, in my home I use an OpenDNS resolver; it's built into my router and I said "yes". If my ISP were implementing 464XLAT (they're not to my knowledge, but imagine) and wanted me to use a prefix of their choosing, OpenDNS could either have no record or give me something different. So the DNS approach has a fairly fundamental flaw.

What might be interesting on routers that want you to configure it manually would be a "use RFC 7050" configuration, in which the router got the record from DNS and advertised it in its RA.

> On Oct 17, 2018, at 11:22 AM, 神明達哉 <[email-masked]> wrote:
> 
> > Well....Some vendors still require the prefix to be explicitly
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: 神明達哉 <[email-masked]>
Date: Thu, 18 Oct 2018 09:11:14 -0700

At Wed, 17 Oct 2018 12:29:11 -0700,
Fred Baker <[email-masked]> wrote:

> I'm not sure we disagree on your point. However, there is also the issue
of shadowing services. For example, in my home I use an OpenDNS resolver;
it's built into my router and I said "yes". If my ISP were implementing
464XLAT (they're not to my knowledge, but imagine) and wanted me to use a
prefix of their choosing, OpenDNS could either have no record or give me
something different. So the DNS approach has a fairly fundamental flaw.
>
> What might be interesting on routers that want you to configure it
manually would be a "use RFC 7050" configuration, in which the router got
the record from DNS and advertised it in its RA.

This made me wonder whether the background assumption is that the
network operator essentially owns leaf routers with some
auto-provisioning system.  In that case, I see the configuration
information is managed effectively only in one place and leaf routers
are automatically configured and updated through the provisioning
system.  In that case I see the configuration overhead is not that
different from the DNS based approach.

--
JINMEI, Tatuya

---

From: Jen Linkova <[email-masked]>
Date: Fri, 19 Oct 2018 23:51:39 +1100

> the number of leaf subnets).

I see your point. I think I just assumed that router configuration
provisioning problem is slightly outside of the scope of this draft.
I need to configure with  much more than 100 routers with:
- PIO (unique config for each interface on each router);
- RDNSS (limited number of configuration templates applied on each inteface)
- other SLAAC options (usually identical for all routers or very
limited number of templates).

Most likely large-scale deployments would need some provisioning
systems anyway so I'm not sure the draft should discuss it - at least
I'm not sure about wording..

> to be configured separately anyway.

Not necessary - one might need to configure RDNSS and timers.

> (right?)

Well, the logic is:
- we should allow more than one PREF64 option per RA (as it would be
needed for renumbering);
- as we can not say 'PREF64 Option can be seen only once' we need to
define the host behavior if multiple prefixes are received;
- for consistency reason we refer to RFC7050.

>Also, if I understand it correctly, "the recommendations

We shall either explicitly prohibit multiple prefixes (which might be
undesirable) or define what to do.

> pref64 option should only support at most one usable prefix.

One option specifies one PREF64 (the same way as one PIO defines one prefix).
Multiple options/multiple prefixes do not make much sense from
operational perspective (IMHO) but I'm not sure we shall say 'MUST
NOT'.

>And then

I see your point - thanks a lot for your comments, it's really
valuable to get a readability feedback. We'll see if we can improve
the text.