Subject: I-D Action: draft-ietf-6man-ra-pref64-02.txt

From: [email-masked]
Date: Tue, 23 Jul 2019 06:40:40 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

        Title           : Discovering PREF64 in Router Advertisements
        Authors         : Lorenzo Colitti
                          Jen Linkova
	Filename        : draft-ietf-6man-ra-pref64-02.txt
	Pages           : 10
	Date            : 2019-07-23

Abstract:
   This document specifies a Router Advertisement option to communicate
   NAT64 prefixes to clients.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-ra-pref64-02
https://datatracker.ietf.org/doc/html/draft-ietf-6man-ra-pref64-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ra-pref64-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 23 Jul 2019 10:09:00 -0400

Hi,

I just reviewed this document and I'm fine with it.

Regards,
Jordi
@jordipalet

El 23/7/19 9:42, "[email-masked] en nombre de [email-masked]" <[email-masked] en nombre de [email-masked]> escribió:

    
    Abstract:

    

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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Martin Hunek <[email-masked]>
Date: Tue, 23 Jul 2019 18:53:00 +0200

Hi,

I've also read the document, and I do have a questions:
1) How do you encode suffix of prefixes other then /96?

According to RFC 6052, the suffix is reserved for future use. In previous version (01) it was straight forward, but in current version the suffix is not mentioned.

Are you planing to embed suffix into the "Highest 96 bits of the Prefix" field?

It would be theoretically possible to do that as a suffix must be always 8b shorter then space not used by non /96 Prefix. But it is not defined how it should be done or how to handle non-zero suffix if it is received. So if the suffix would be decided to be used some day, then your document would have to be updated accordingly.

Could you make the "Highest 96 bits of the Prefix" to: Prefix (up to 96b), if less followed by zeroes (8b) then suffix? If this is your intention.

2) How should a Router behave when it receives this option from its upstream?

This is actually question I've asked you at IETF 104. When you have an topology in which the operator would send Pref64 option in its RAs and to this link the customer router (CPE) would be connected. Then customer devices would be connected after that router. Should that Pref64 option be transitive trough CPE, so it would get to those devices behind CPE? Or should be non-transitive so it would be only used for traffic generated by router itself? I think that this should be specified by the document.

I would suggest smth like:
"When Pref64 is received by a router on its upstream interface and a router is sending RAs on its downstream interfaces. A router SHOULD include Pref64 option learned on its upstream interface into RA send on downstream interfaces, if not configured with different NAT64 prefix."

Otherwise I support this idea. But especially question 2 should be addressed in the document or you would solve NAT64 detection only in one segment / on link as it would not work over CPE or in case that user itself would connect two routers after each other (yes, I've seen that, there are such people out there :-) ).

Regards,
Martin

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Jul 2019 14:05:35 -0400

On Tue, Jul 23, 2019 at 12:54 PM Martin Hunek <[email-masked]> wrote:

> According to RFC 6052, the suffix is reserved for future use. In previous
> version (01) it was straight forward, but in current version the suffix is
> not mentioned.
>

In the ~decade since RFC 6052 was written, I don't know of any use of the
suffix. Do you?

Also, I believe none of the other methods to discover the NAT64 prefix
communicate the suffix either.

> This is actually question I've asked you at IETF 104. When you have an
> topology in which the operator would send Pref64 option in its RAs and to
> this link the customer router (CPE) would be connected. Then customer
> devices would be connected after that router. Should that Pref64 option be
> transitive trough CPE, so it would get to those devices behind CPE? Or
> should be non-transitive so it would be only used for traffic generated by
> router itself? I think that this should be specified by the document.
>

I think that is out of scope for this document, which is a standards track
document. I think we would need operational experience before we could
credibly make recommendations on how routers should act on this option.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 24 Jul 2019 04:19:14 +1000

Hi Martin,

> 1) How do you encode suffix of prefixes other then /96?

Ah, good point. The question is: do we need to?
The existing standard says  the suffix SHOULD be 0.

> This is actually question I've asked you at IETF 104. When you have an topology in which the operator would send Pref64 option in its RAs and to this link the customer router (CPE) would be connect…

I do not believe it belongs to this draft. This draft specifies the
option format, how router sends it in RA and how hosts processes it.
What you are describing looks like CPE requirements and would belong
to v6ops. AFAIR we do not specify 'transitiveness' for any other RA
options. IMHO it should belong to a document which describes how
routers shall receive configuration from WAN and send it downstream,
not to the standard track which defines the option format.

> Otherwise I support this idea. But especially question 2 should be addressed in the document or you would solve NAT64 detection only in one segment / on link as it would not work over CPE or in cas…

I guess those people configure other RA options on the downstream
interfaces somehow anyway (PIOs, RDNSS etc) - I'm not sure what's the
point of propagating Pref64 downstream while PIOs/RDNSS still need to
come from somewhere else.

--
SY, Jen Linkova aka Furry

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 23 Jul 2019 14:24:04 -0400

Responding to the CE part.

I think, ideally, once this document is approved, we could work in an RFC8585-bis to update that.

Regards,
Jordi
@jordipalet

El 23/7/19 14:20, "ipv6 en nombre de Jen Linkova" <[email-masked] en nombre de [email-masked]> escribió:

    Hi Martin,

---

From: David Farmer <[email-masked]>
Date: Tue, 23 Jul 2019 14:16:05 -0500

> not to the standard track which defines the option format.

I think I agree with your point regarding receiving this RA option on a WAN
interface and agree with Jordi that if that is desired it belongs in
an RFC8585-bis anyway.

However, It could be a useful option from a network operator point of view
for a router to informationally log the reception of an RA with different
Pref64 information than is configured on the router's interface, i.e. a
different router is sending different Pref64 information on the LAN.
Basically following the first rule of security, if you see something that
doesn't seem right, say something.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Jen Linkova <[email-masked]>
Date: Thu, 25 Jul 2019 23:48:24 +1000

On Wed, Jul 24, 2019 at 5:16 AM David Farmer <[email-masked]> wrote:
> I think I agree with your point regarding receiving this RA option on a WAN interface and agree with Jordi that if that is desired it belongs in an RFC8585-bis anyway.
>
> However, It could be a useful option from a network operator point of view for a router to informationally log the reception of an RA with different Pref64 information than is configured on the router's interface, i.e. a different router is sending different Pref64 information on the LAN. Basically following the first rule of security, if you see something that doesn't seem right, say something.

Actually  would be inline with https://tools.ietf.org/html/rfc4861#section-6.2.7
which states that
"Routers SHOULD inspect valid Router Advertisements sent by other
   routers and verify that the routers are advertising consistent
   information on a link.  Detected inconsistencies indicate that one or
   more routers might be misconfigured and SHOULD be logged to system or
   network management.  "

We've just submitted -03 which has a section on the consistency.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 26 Jul 2019 00:07:46 +1000

> Could you make the "Highest 96 bits of the Prefix" to: Prefix (up to 96b), if less followed by zeroes (8b) then suffix? If this is your intention.

After thinking about it for a while...So sending only first 96 bits
does not save us any bits on the wire (it would just increase the
Reserved field) so we've just posted -03 when we reverted the option
format to '3 bytes Reserved and all 128 bits of Pref64'. It would
allow to send the suffix if we need it one day.

---

From: David Farmer <[email-masked]>
Date: Thu, 25 Jul 2019 09:08:46 -0500

On Thu, Jul 25, 2019 at 8:48 AM Jen Linkova <[email-masked]> wrote:

> > I think I agree with your point regarding receiving this RA option on a
> WAN interface and agree with Jordi that if that is desired it belongs in an
> RFC8585-bis anyway.
> >
> > However, It could be a useful option from a network operator point of
> view for a router to informationally log the reception of an RA with
> different Pref64 information than is configured on the router's interface,
> i.e. a different router is sending different Pref64 information on the LAN.
> Actually  would be inline with
> https://tools.ietf.org/html/rfc4861#section-6.2.7
> which states that

I looked at -03, I think it covers my suggestion.

Thanks

---

From: David Lamparter <[email-masked]>
Date: Thu, 25 Jul 2019 16:09:15 +0200

> 1) How do you encode suffix of prefixes other then /96?

I've looked at the -02 draft and I agree that this section of the
document was worded confusingly, especially with the diagram.  Before
hitting send on this mail I noticed -03 fixes it, so thank you on that
(both Martin for raising the issue and Jen & Lorenzo for fixing it.)

Speaking as a FRR maintainer - "we send RAs" - I'm comfortable that the
-03 draft is well-shaped and sufficient for implementation, i.e. I'd be
able to either review a PR implementing it or implement it myself.

-David