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

From: "David B Harrington" <[email-masked]>
Date: Wed, 31 Mar 2010 12:51:14 -0400

Hi,

These comments have not been addressed in -06-.
Please address them.

Thanks,
dbh

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: Tuesday, March 16, 2010 8:51 AM
> To: [email-masked]
> Subject: review of draft-ietf-behave-address-format-05
> 
> 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.
> 

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