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

[Suresh Krishnan <[e-mail]>]

Hi Lorenzo,
  Thanks for the quick response!

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

On Sat, 2 Nov 2019, 12:49 Suresh Krishnan, <[e-mail]<mailto:[e-mail]>> 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

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

A better reference might be RFC7556.

Works for me.


"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

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