Subject: [BEHAVE] review of draft-ietf-behave-address-format-05

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Mar 2010 08:50:39 -0400

Hi,

I reviewed draft-ietf-behave-address-format-05 and have comments.

section 1.3 Terminology defines terms that are defined using different
words in the framework document. I recommend having one document
define the term and other documents only reference it (preferred), or
copy the text so the documents have exactly the same definition and
point to the other document as the authroitative definition.

section 1.3 

The format document uses "IPv4-Converted", while framework uses
"IPv4-converted". we should use consistent capitalization rules.

the terms should be organized in alphabetical order.

section 2.1 

says to concatenate [...] the null suffix. But the suffix may in the
future be non-null. s/null suffix/suffix/

"   o  If the prefix length is less than 96 bits, remove the last
octet
      and insert the null octet "u" at the appropriate position, as
      documented in Figure 1." 

I find this ambiguous. "Remove the last octet" could refer to the last
octet of the prefix. It doesn't mention shifting the bits in position
64-119 into positions 72-127. Specify the "appropriate position"
(which is a fixed position).

   o  for the other prefix lengths, extract the "u" octet to obtain a
      120 bit sequence, then extract the 32 bits following the prefix.

is equally ambiguous. When you extract the "u" octet, you do not
obtain a 120-bit sequence, you obtain the "u" octet. What you really
need to do is shift the bits in position 72-127 into positions 64-119
and zero the bits in position 120-127 (to make sure the uninitialized
bits are not interpreted as being a non-null suffix).

I describe shifting the bits; but if we expect to allow non-null
suffixes in the future, then you really need to extract the values of
portions of the address, and concatenate the extracted portions, so
that you preserve the original address format, including the suffix. 

section 2.2

in the first paragraph, the second sentence isn't needed. Its presence
raises questions of whether this is in addition to the formats
specified in rfc4291, or whether it is describing a specific example
of a format described in rfc4291. If you keep it, I recommend starting
the second second with "For example," and removing "Examples of" from
the third paragraph.

section 3.1

The paragraphs would seem better ordered MUST-SHOULD-MAY rather than
MAY-SHOULD-MUST. In particular, the MAY is an exception to the SHOULD,
and should follow the description of SHOULD behavior.

The second paragraph s/Translatable addresses/Translatable IPv6
addresses/
"Translatable addresses" is not defined in terminology. There may be
other types of translatable addresses besides those discussed in this
document. 

section 3.2

"owing to" is unclear. Please reword.

Advertisement [...] SHOULD be controlled by upstream or downstream
providers. Assuming up and down stream are the only two options, this
means there are circumstances where advertisement of WKP does not need
to be controlled. When is this acceptable (i.e., why is control not a
MUST?)

Is the ability to control mandatory to implement? If not, what if an
upstream provider doesn't implement support for control, and the
downstream provider doesn't implement support for control. This means
they cannot control because neither provider's device implemented it.
Should this be mandatory to implement, but administratively
configurable as to which provider provides the control?

Shouldn't both ends be able to control advertisements? One should be
able to control sending the advertisements; the other should be able
to control receiving advertisements. Which has which responsibility
should be deployment-specific.

s/induces/introduces/

"   Administrators of BGP nodes SHOULD configure filters that discard
   advertisements of embedded IPv6 prefixes longer than the Well-Known
   Prefix."
Is this true for ALL embedded prefixes, or only those embedding the
WKP?
(also see the first sentence in the same paragraph)

where is "hair-pinning" defined? needs a reference.

"must be able to"
"may require" - please use different wording to avoid RFC2119
confusion.

s/require/REQUIRE/ (or reword to use MUST):
   Routers MUST
   check the validity of the IPv4-Translatable IPv6 source addresses
   using some form of reverse path check, as detailed in Section 4
Security considerations.

the "small example" seems to cover multiple paragraphs. I am not sure
where the example ends. Can the example be put into a separate section
(or sub-section)?

Where is "all-zeroes identifier" defined? needs a reference.

"   We propose here a compromise, based on using no more than 1/256th
of
   an organization's allocation of IPv6 addresses for the IPv4/IPv6
   translation service. For example [...]" 
Where exactly is the proposal? 
Is this proposal a MUST, a SHOULD, or a MAY? Please use RFC2119
language.

This whole section seems to present a variety of proposals, and the
pros and cons of each approach. What is being standardized? Or are we
not standardizing the prefix usage and source checking? Can we put the
evaluation of propoals and pros and cons into a separate section from
the section that standardizes an approach?

If different deployemnts use different approaches, what can be
expected in terms of security and operations? Does the decision of one
deployer potentially decrease the security assured to a neighboring
deployment? How can one deployemnt learn what decisions were made by
the neighbor?

"The recommended prefix length" - please use RFC2119 language.

"   IPv4-Translatable IPv6 addresses SHOULD follow the IPv6 address
   architecture and SHOULD be compatible with the IPv4 address
   architecture."
Please include an explanation of when the SHOULDs do not apply.

s/SHOULD not/SHOULD NOT/

"In addition,
   the minimum IPv4 subnet can be used for hosts is /30 (the router
   interface needs a valid address for the same subnet) and this rule
   SHOULD also be applied to the corresponding subnet of the IPv4-
   translatable addresses."
please use RFC2119 language (can be, needs, etc.), and explain when
SHOULD does not apply.

section 3.4

please use RFC2119 language.

s/using same prefix/using the same prefix/

"The Well-Known Prefix MUST NOT be used for scenario 3  [...] That
means a
      Network-Specific Prefix MUST be used in that scenario, for
example
      a /96 prefix compatible with the Well-Known prefix format."
Huh? I don't understand what a NSP compatible with the WKP format
means. I understood the paragraph up until the example.

section 3.5

please use RFC2119 language, for example, s/recommends/RECOMMENDS/

This whole section talks about potential choices for non-null
suffixes. But starts by saying "section 2 RECOMMENDS a zero suffix".
Section 2 says "These bits are reserved for future extensions, and
SHOULD be set to zero." So why are we discussing potential future
extensions in this document? Let's leave that to future extension
documents, and simply say here "the suffix bits SHOULD be set to
zero." For implementations compatible with THIS document, there is no
choice of suffix.

"because
   checksum neutrality can also be achieved by an appropriate choice
of
   the Network-Specific Prefix, as was done for example with the Well-
   Known Prefix."
I don't understand how the example achieved checksum neutrality, so
the example doesn't actually help explain "an appropriate choice".

In section 2.1, the suffix with bits all zeroed is called the "null
suffix", but here it is called the "zero suffix". Please be
consistent.

section 3.6

This is not deployment guidelines. This is history of how the WG
reached its decisions. While this can be useful to preserve, it
probably belongs in an appendix (or in a "The Making of" movie.) For
implementations compatible with THIS document, there is no deployment
choice of WKP.

section 4.1

s/By and large,//

"the same mitigations" - can you provide some pointers to documents
thta discuss the risks and mitigations that apply?

reverse path checks - can you provide a reference?
packets are coming from an authorized location - can you provide a
reference?

section 4.2

s/to be the configured/to be configured/
s/As such,//
s;learned/configured;learned and configured;

The IETF has standardized a number of approaches to securely
configuring devices. Please add some suggestions of standardized
secure means of configuration.

section 5

Doesn't IANA need to assign the specific value out of the
IETF-reserved range?
Can you provide a reference to the document that says no IANA action
is required for using values in this range?

section 6 and 7

The IETF is an organization of individuals. We do not provide
addresses and funding sources for everybody acknowledged in the
Acknowledgement section.

I consider it inappropriate to specify who is funding Marcelo, and to
provide full addresses for individuals who co-authored drafts that
were NOT used as the WG draft, even though the WG draft incorporated
text from some of those drafts. 

Please add the names to the acknowledgements section, without
organizational addresses and funding information.

Only the authors' addresses section should carry this information, so
the authors can be contacted regarding THIS document. 

dbh

David Harrington
[email-masked]
[email-masked]
[email-masked]