Subject: Re: Chairs review of <draft-ietf-6man-ra-pref64-04>

From: David Lamparter <[email-masked]>
Date: Tue, 3 Sep 2019 15:21:34 +0200

On Fri, Aug 30, 2019 at 01:59:10PM +1000, Jen Linkova wrote:
> On Fri, Aug 30, 2019 at 1:52 PM Lorenzo Colitti
> <lorenzo=[email-masked]> wrote:
> >
> > On Fri, Aug 30, 2019 at 12:34 PM Bob Hinden <[email-masked]> wrote:
> >>
> >> We understand the reason for the format, we were asking if the resulting complexity of having essentially two different formats was worth the complexity.   It would make it simpler if there was just a prefix length and an address, like is done elsewhere in ND.   Is the saving in length work the extra complexity in the document and in implementations?
> >
> >
> > Personally, I think so. It doesn't greatly complicate implementations - it's just slightly complicating the parsing code. It's not making complex behaviour changes which would complicate the state machine. I think the space savings are worth it - the space in RAs is limited because we don't allow fragmentation.
> 
> +1. There are pros and cons for both approaches but having another
> format requires implementors to do some work *once* (I'm not an
> implementor so I do not know how much work we are adding to their
> plate by introducing the new format (adding David who has wrote some
> code). But saving size might pay off in future...

This is a few lines of complexity - just talking about it here takes
more time than implementing it, really.

Also, I wouldn't look at this as "implementation cost vs. byte savings",
rather I would compare "cost of this vs. cost of dealing with fragmented
RA/ND."  I've recently spent some time on /that/ can of worms, and even
just ignoring or discarding fragmented ND is hard to do correctly when
you take the router or L2 switch (SAVI) perspective with hardware paths
coming into play.

IMO: Just make sure all expected behaviour is well described, especially
for malformed options.  /someone/ will always pay cheapest labour to
implement things, and they /will/ find opportunities to shoot themselves
in the foot.

-David

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Sep 2019 10:00:30 +0200

> more time than implementing it, really.

Good. I still think it is uneccesary, but if no-one else agrees with me I will let it go.

> you take the router or L2 switch (SAVI) perspective with hardware paths

I don't think the choice of length=2 or 3 will make any difference in that regard.

> implement things, and they /will/ find opportunities to shoot themselves

Yes, which is another argument against the current format.
If your cheap labour argument holds true, we will likely see implementations supporting only length=2.
That will lead to no interoperability on networks with a NAT64 prefix length != 96.
Why should we leave that door open for interoperability?

Best regards,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Sep 2019 10:04:25 +0200

Lorenzo,

See my answer to David with regards to the format.
We don't have to solve the problem of overrunning the packet space in this draft, so I will not comment on that.

Regarding document progress.
In addition to the format issue, the other issues will also have to be addressed in a new revision.

Best regards,
Ole

> On 31 Aug 2019, at 09:20, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Fri, Aug 30, 2019 at 5:09 PM Ole Troan <[email-masked]> wrote:
> There is only going to be one of these options in a packet (most of the time).
> Inventing a new prefix representation purely to save 8 bytes just doesn't seem worth it. Contrast that with the PIO option where 16 bytes are always used.
> 
> Well, 8 bytes is a 50% increase.
> 
> If we run out of space; a) split the RA into multiple packets
> 
> Now that, on the other hand, *would* substantially complicate implementations. Obviously, it would complicate router implementations, which AFAIK support only one RA packet.
> 
> Hosts do have to deal with multiple RAs today, though I don't know how well they actually do. But even if they do, splitting the RA impacts application reliability due to non-atomic configuration. This is because in the common case (yes, not guaranteed - but the common case is pretty much universal), configuration via RA is atomic in the sense that only one packet is enough to convey a complete L3 configuration to hosts. This is good. For an example of why non-atomic configuration is bad, consider the following RAs:
> 	• RA with PIO, RDNSS and default router.
> 	• RA with PREF64.
> There are two problems with this. First, there is a race condition between the network stack and applications. As soon as the host receives RA #1, it will think it's connected to an IPv6-only network. It will tell applications that the network is connected. Unfortunately, applications that need to talk to IPv4-only servers will fail until RA #2 arrives, because synthesis cannot occur without knowing the NAT64 prefix. If the network provides a DNS64 server, things go better... unless user-defined DNS servers (e.g., a trusted DoT or DoH server) are in use, or the host wants to do DNSSEC validation. In a world where DNSSEC is widely deployed, this is either a hard failure or a window for a downgrade attack.
> 
> Second, a reliability problem. If RA #2 gets lost (which can happen), the host is in limbo, with IPv4 applications similarly broken until the next periodic multicast RA arrives. For a battery-powered host, that will be several *minutes* if the network follows the best practices in RFC 7772. Also, even if things go well on initial connect, the problem can occur later on. If the host gets unlucky with packet loss, RA #2 could expire before RA #1 expires. In that case, IPv4-only applications might stop working again even though the host does not disconnect.
> 
> What can the stack do? Obviously, it *cannot* just wait until RA #2 arrives because on a truly IPv6-only network (as opposed to an IPv6-only network with NAT64), it will never arrive. It can retransmit RSes periodically hoping that a pref64 will arrive, but that costs battery power, and, well, implementations don't do this today (and based on previous conversations on the list I don't think we even have consensus that the standard allows it). That is what I meant in my earlier message about implementation complexity. Compared with dealing with a problem like this, supporting both 16-byte and 24-byte option formats is absolutely trivial - it's basically just a couple more lines of parsing code. Sure, you could say that it will be several years before this becomes a problem, but if PVDs take off then RAs may get a lot bigger and extra bytes will matter more than they do today.
> 
> So, again, my vote is to keep the smaller option format, and indeed, to ensure that as we (6man) define new RA options, we don't waste space in the RA.

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Sep 2019 18:35:21 +0200

Lorenzo,

Since the prefix has a max length of 96, you could also do:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |  Lifetime      |  Prefix len  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |              Highest 96 bits of the Prefix                    |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And prefix length could even be 3 bits.

Cheers,
Ole

> On 5 Sep 2019, at 10:04, Ole Troan <[email-masked]> wrote:
> 
> Lorenzo,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Jen Linkova <[email-masked]>
Date: Fri, 6 Sep 2019 09:44:02 +1000

On Fri, Aug 30, 2019 at 5:04 PM Ole Troan <[email-masked]> wrote:
> >>> Also, could the distinction be made clearer about which is to configure NAT64 and which to configure DNS64?
> >>
> >>
> >> I'm not sure I understand this comment. This option communicates the NAT64 prefix. The prefix is needed/useful for the various things listed in that section, including DNS64 validation, local DNS64 synthesis, etc. These have in common the fact that they all need to know the prefix.
> >
> > I read this as a suggestion to split those use cases into two groups:
> > 1) Allowing host to perform DNS64 functions (Local DNSSEC validation,
> > Trusted DNS server, networks w/o DNS64 at all)
> > 2) allowing hosts to perform NAT64 address synthesis (464XLAT and IPv4
> > literals cases)
>
> Exactly.
> Since the DNS and NAT functions got split after NAT-PT, it's good to be consistent and continue to treat them as separate functions.

Ack. The text will be updated in  -05. Stay tuned.

-- 
SY, Jen Linkova aka Furry

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Sep 2019 08:54:43 +0900

> Since the prefix has a max length of 96, you could also do:

An 8-bit lifetime is not enough, though: it should be at least as long as
the RA lifetime. Basically you have 1 type, 1 length, 2 lifetime, 12 prefix
and that's 16 bytes, the maximum for len=2. Anything else puts you at len=3.

I proposed assigning 3-bits to the prefix length and 5-bits to the lifetime
(on receipt it would be mulitplied by 8), but my co-author was so
mercilessly opposed to it that I don't think we ever presented it to the WG
:-)

---

From: Jen Linkova <[email-masked]>
Date: Fri, 6 Sep 2019 11:49:57 +1000

On Sat, Aug 31, 2019 at 1:03 AM Bob Hinden <[email-masked]> wrote:
> > If we explicitly mandate 'drop the option if Length > 3'
> > we would never be able to add anything later. So while 'drop'  does
> > not add any additional benefits it limits what we can do in the
> > future.
>
> Sorry, what would you want to add in the future?   I didn’t read anything in the draft about future extendability.  It seems to me like this document does one thing.  Shouldn’t other things be done in different options?

Well, let's imagine for a second (for the record: I'm not proposing
it, it's just an example) that one day we decide that, as Mark has
proposed, we must provide a list of addresses NOT to be translated
using the specific prefix. Or some other information which is
prefix-specific so should be bundled with the prefix option.

I see it as being liberal in what you accept from others. I do not see
any problems with allowing Length >3 and just ignoring bits we do not
know how to process - but I might be missing smth here...

---

From: Jen Linkova <[email-masked]>
Date: Fri, 6 Sep 2019 11:50:32 +1000

> In addition to the format issue, the other issues will also have to be addressed in a new revision.

Sure, working on it, stay tuned - sorry for the delay.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 5 Sep 2019 19:53:21 -0700

Jen,

> On Sep 5, 2019, at 6:49 PM, Jen Linkova <[email-masked]> wrote:
> 
> know how to process - but I might be missing smth here…

I sort of get it, but that’s pretty far out there.   Not clear to me what it means to get one of these packets but you don’t have the code to support it.   Having a link with where some nodes understand the non-translated address, and other nodes don’t seems problematic.

Receiving a packet with a lot more than the required data, might allow for all kinds of mischief and/or security issues.

Bob

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Sep 2019 08:43:31 +0200

Jen,

> know how to process - but I might be missing smth here...

Now you have 3(1) different implementations out there:

1) Those that don't support this option
2) Those that only support 96 bits prefix length (l=2)
3) Those that support arbitrary prefix length (l=2, l=3)
4) Those that support some new options (l>3)

You could merge 2+3 into one with a different packet format. And drop 4 by not allowing extensions.
This almost tempts me to revitalize the universal ra draft. 

Best regards,
Ole

1: There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 6 Sep 2019 07:58:35 -0700

Lorenzo,

> On Sep 5, 2019, at 4:54 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> An 8-bit lifetime is not enough, though: it should be at least as long as the RA lifetime. Basically you have 1 type, 1 length, 2 lifetime, 12 prefix and that's 16 bytes, the maximum for len=2. Anything else puts you at len=3.
> 
> I proposed assigning 3-bits to the prefix length and 5-bits to the lifetime (on receipt it would be mulitplied by 8), but my co-author was so mercilessly opposed to it that I don't think we ever presented it to the WG :-)

I like that approach (that is, 3-bit prefix length field) given that RFC6052 limits the prefix length to a limited set of values (32, 40, 48, 56, 64) so it easy to encode.   The resulting format and processing would be much simpler.

This draft is now a w.g. draft, so it’s what the w.g. wants that is important.

Bob

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Sep 2019 12:42:07 +0100

Jen Linkova <[email-masked]> wrote:
    > Well, let's imagine for a second (for the record: I'm not proposing it,
    > it's just an example) that one day we decide that, as Mark has

    > know how to process - but I might be missing smth here...

I agree.

This is an RA, on a LL, so it's not like we have to worry about some
intermediate router needing to enforce some firewall rules on this option.

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

---

From: Jen Linkova <[email-masked]>
Date: Mon, 9 Sep 2019 15:05:15 +1000

On Fri, Sep 6, 2019 at 4:43 PM Ole Troan <[email-masked]> wrote:
> You could merge 2+3 into one with a different packet format.

I'm not sure I understand. If an implementation decides to support
only /96 Pref64 it has very little to do with the option format.
I suspect we might (and probably will) have implementations supporting
/96 only even if we decide to waste RA bits and  always include the
prefix length field.

>And drop 4 by not allowing extensions.

I do not have a strong opinion re: extension, I was thinking that
allowing extension does not have any disadvantages and might be
beneficial later. If you believe L > 3 introduces issues we can drop
this.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 9 Sep 2019 15:26:48 +1000

> I like that approach (that is, 3-bit prefix length field) given that RFC6052 limits the prefix length to a limited set of values (32, 40, 48, 56, 64) so it easy to encode.   The resulting format an…

3-bits prefix length is not a problem. What scares me is  5-bits
lifetime (so the actual lifetime would be calculated by  multiplying
the filed value by 8).
IMHO it's quite far from being 'simpler to process'.

> This draft is now a w.g. draft, so it’s what the w.g. wants that is important.

Absolutely. So let's find out what the w.g. wants (as I'm not sure, to
be honest).
Options we have (hopefully I did not miss any)

1) use the format described in the draft right now.
Pros:
  - in majority of the cases it keeps the option size to min. and only
adds 8 bytes if non-96 prefix is used
Cons:
  - new format which requires implementors to do smth new to parse the
option (however at least one implementor does not think it's a problem
at all)

2) Always have option length = 3 (16 bits lifetime, 8 bits prefix
length, 128 bits prefix).
Pros:
- easy to parse
Cons:
- in majority of the cases (the current assumption is that non-/96 is
rarely used) we'll be wasting bits in RA. RAs can not be fragmented
and dealing with multiple RAs from one router has a number of issues
as Lorenzo has described in this thread.

3) Lorenzo's idea (which we have not presented to the WG before):
assigning 3-bits to the prefix length and 5-bits to the lifetime (on
receipt it would be multiplied by 8),
Pros:
- keep the option size to minimum (length = 2) all the time
Cons:
- it's a new format again
- complex  to implement (I suspect it might lead to implementation
bugs..) and troubleshoot (the lifetime I see in my .pcap is not one
being actually applied? shall we give people one more reason to
complain that IPv6 is soooo hard to understood?)
- not all lifetime values can be encoded

Did I miss any other options/pros&cons?

So what does the group want?

---

From: Ole Troan <[email-masked]>
Date: Mon, 9 Sep 2019 07:50:16 +0200

> IMHO it's quite far from being 'simpler to process'.

It would be a 13 bit lifetime field, no? Left shift by 3 to get seconds.
At some point it might be worth having a discussion of the use and value of lifetimes in these options...

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 9 Sep 2019 07:52:48 +0200

Jen,

> beneficial later. If you believe L > 3 introduces issues we can drop

How do you plan for interoperability if you allow for implementations only supporting /96 and for extensions?
How is the network operator going to deal the number of mutations of host implementations?
 - hosts only supporting /96
 - hosts supporting extension A, B or Z
 - hosts not supporting Pref64, but 7050
 - hosts supporting only PCP
 - hosts supporting only DHCP option

Are you really sure you want more permuations? ;-)

Best regards,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Sep 2019 15:07:45 +0900

> /96 only even if we decide to waste RA bits and  always include the

Absolutely. Supporting non-/96 in a host is much more complex than just
parsing this option. Many implementations (including, at least, Android)
support only /96 today, even though RFC 7050 allows discovering
different prefix lengths. Also, it depends on what deployments those
devices are targeting. I am only aware of one network that does not use /96
today.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 9 Sep 2019 16:08:28 +1000

On Mon, Sep 9, 2019 at 3:50 PM Ole Troan <[email-masked]> wrote:
> It would be a 13 bit lifetime field, no?

Yes, my fault, copy-n-paste w/o doing the math ;)
13 bit. Still not 16 bits. So all cons apply:
- not all lifetime values can be encoded (I'm aware of deployments
where router lifetime and MaxRtrAdvInterval/MinRtrAdvInterval are set
to quite low values);
- it makes the protocol and the troubleshooting unnecessary complicated.
etc

>Left shift by 3 to get seconds.

> At some point it might be worth having a discussion of the use and value of lifetimes in these options...

Lifetimes are *very* useful. One of the key benefit is to be able to
notify hosts about changes. I need to be able to deprecate the prefix
(and other configuration parameters) and propagate the changes to
hosts.
Yes, I'm doing it *often* and I do not expect that need to disappear
any time soon.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 9 Sep 2019 16:16:46 +1000

> How do you plan for interoperability if you allow for implementations only supporting /96 and for extensions?

I guess the same way we'd deal with adding any new options to RAs....

> Are you really sure you want more permuations? ;-)

I don't but I think we can not avoid it if we want new features in the protocol.

Anyway, as I've said, I do not have any strong feelings about L>3 so
I'll update the text in the -05.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Sep 2019 15:17:33 +0900

> - it makes the protocol and the troubleshooting unnecessary complicated.

"Not all lifetime values can be encoded" means that the lifetime of the
NAT64 prefix will sometimes be different than the ones of the other fields
in the RA, and thus expire at different times, which is bad. That said,
often-used lifetimes such as x hours, x days, etc. are divisible by 8 so
perhaps this is not too bad. n*10 minutes is not divisible by 8 but n*20
minutes and n*30 minutes are.

> Yes, I'm doing it *often* and I do not expect that need to disappear

Absolutely. In networking, things change all the time. If the network
cannot inform the host that something has changed, then the only
alternative left is that the network pretends that something didn't change
with things like NAT and VRRP.

---

From: Ole Troan <[email-masked]>
Date: Mon, 9 Sep 2019 08:21:06 +0200

Jen,

> Yes, I'm doing it *often* and I do not expect that need to disappear

Yes, but are you actually adhering to the lifetime?
The lifetime as used in RA can be thought of as a promise by the network. This service (address or whatever) is promised to be valid for at least this amount of time. I expect what you do is to break that promise. E.g state, sure Ms Host the NAT64 prefix is valid for the next 7 hours, then turn around 30 seconds later and state, gee, btw, it's now invalid. And if that's the use of this, perhaps a more explicit mechanism would be better. Ref. flash renumbering of address prefixes. Anyway, I think this is a larger discussion outside of the scope of pref64.

Cheers,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Mon, 9 Sep 2019 16:30:30 +1000

> On 9 Sep 2019, at 3:26 pm, Jen Linkova <[email-masked]> wrote:
> 
> IMHO it's quite far from being 'simpler to process’.

Well it would be 13-bits of lifetime if 3-bits for prefix length where used as
lifetime + prefix len is 16-bits.  To get the same range for lifetimes as other
options multiply by 8 (read in bits 16..31 as a network short, covert to host order
and &= ~0x7 to get the lifetime.

	lifetime = ntohs(bits16to32) & ~0x7;

	unsigned char table[8] = { 32, 40, 48, 56, 64, 96, 0, 0 };
	prefixlen = table[ntohs(bits16to32) & 0x7];
	if (prefixlen == 0) goto err;

	or

	unsigned char table[8] = { 32, 40, 48, 56, 64, 96, 0, 0 };
	lifetime = ntohs(bits16to32);
	prefixlen = table[lifetime & 0x7];
	lifetime &= ~0x7;
	if (prefixlen == 0) goto err;

> - not all lifetime values can be encoded

Actually it is trivial to implement.  See above. 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]