-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
On 02/19/10 02:00, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
>
>
> Title : A Recommendation for IPv6 Address Text Representation
> Author(s) : S. Kawamura, M. Kawashima
> Filename : draft-ietf-6man-text-addr-representation-06.txt
I've reviewed the draft and am supportive of it moving forward. I've
attached a diff with some edits that I hope are useful. Whether the
edits are included or not I am still supportive of the draft.
My suggested changes are almost all of the "wordsmithing" variety. In
rough order of frequency:
1. Removed a lot of commas. (I have a tendency to add too many commas
myself so I'm particularly sensitive to this when reading other people's
work.) :)
2. Removed a lot of lines of the nature "Examples of this are below."
These lines did not add clarity to the text (as it was already clear
that the examples were examples).
There are two "substantive" changes. First, in section 3.1.2 I thought
that the duplicate address example was weak and unnecessary, so I
deleted it. (Wouldn't DAD handle this?)
The more substantive change is the section I added:
4.2.4. Exception to the "::" Shortening Rule
When it is necessary to record an address with consecutive 16 bit 0
fields without the use of the "::" symbol, for example in a database,
each such field SHOULD be represented with one, and only one zero. For
example 2001:db8:0:0:0:0:0:1. However when the address is written out
for human consumption the "::" MUST be used as described in the sections
above.
I realize that this idea has complications, not the least of which is
that it seems to be creating an exception to the idea of a "canonical"
text representation. However in just the little bit of work that I've
done with recording, comparing, etc. IPv6 addresses I've already run
into situations where this is useful, and I think that it would be
beneficial to document the concept so that people who face the same
issue will have some guidance in how to proceed. If the group does not
agree that this is useful I have no problem with it not being included.
Regards,
Doug
- --
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
iEYEAREDAAYFAkuAp1oACgkQyIakK9Wy8PuU4QCgru6RLC1bWByAw/g5uVlL35mM
/TUAnjvO1e3fRMYpuBPFD9S/QSyyOO5w
=wpuq
-----END PGP SIGNATURE-----
--- draft-ietf-6man-text-addr-representation-06.txt.orig 2010-02-20
15:14:38.000000000 -0800
+++ draft-ietf-6man-text-addr-representation-06.txt 2010-02-20
19:21:55.000000000 -0800
@@ -13,10 +13,10 @@
Abstract
- As IPv6 network grows, there will be more engineers and also non-
- engineers who will have the need to use an IPv6 address in text.
- While the IPv6 address architecture RFC 4291 section 2.2 depicts a
- flexible model for text representation of an IPv6 address, this
+ As IPv6 deployment increases there will be a dramatic increase in the
+ need to use IPv6 addresses in text.
+ While the IPv6 address architecture in RFC 4291 section 2.2 describes a
+ flexible model for text representation of an IPv6 address this
flexibility has been causing problems for operators, system
engineers, and users. This document will describe the problems that
a flexible text representation has been causing. This document also
@@ -24,7 +24,7 @@
confusion. It is expected that the canonical format is followed by
humans and systems when representing IPv6 addresses as text, but all
implementations must accept and be able to handle any legitimate
- RFC4291 format.
+ RFC 4291 format.
Status of this Memo
@@ -171,8 +171,7 @@
1. Introduction
- A single IPv6 address can be text represented in many ways. Examples
- are shown below.
+ A single IPv6 address can be text represented in many ways:
2001:db8:0:0:1:0:0:1
@@ -190,11 +189,10 @@
2001:DB8:0:0:1::1
- All the above represent the same IPv6 address. This flexibility has
+ All of the above examples represent the same address. This flexibility has
caused many problems for operators, systems engineers, and customers.
- The problems will be noted in Section 3. Also, a canonical
- representation format to avoid problems will be introduced in
- Section 4.
+ The problems are noted in Section 3. Also, a canonical
+ representation format to avoid problems is introduced in Section 4.
1.1. Requirements Language
@@ -213,10 +211,9 @@
'It is not necessary to write the leading zeros in an individual
field.'
- In other words, it is also not necessary to omit leading zeros. This
- means that, it is possible to select from such as the following
- example. The final 16 bit field is different, but all these
- addresses mean the same.
+ Conversely it is not necessary to omit leading zeros.
+ The final 16 bit field is different, but all of these
+ examples represent the same address:
@@ -238,15 +235,14 @@
'A special syntax is available to compress the zeros. The use of
"::" indicates one or more groups of 16 bits of zeros.'
- It is possible to select whether or not to omit just one 16 bits of
- zeros.
+ Whether or not to omit just one 16 bit field of zeros is optional.
2001:db8:aaaa:bbbb:cccc:dddd::1
2001:db8:aaaa:bbbb:cccc:dddd:0:1
- In case where there is more than one zero fields, there is a choice
- of how many fields can be shortened. Examples follow.
+ In cases where there is more than one field of only zeros there
+ is a choice of how many fields can be shortened.
2001:db8:0:0:0::1
@@ -260,8 +256,8 @@
'The "::" can only appear once in an address.'
- This gives a choice on where, in a single address to compress the
- zero. Examples are shown below.
+ This gives a choice of where in a single address to compress the
+ zeros.
2001:db8::aaaa:0:0:1
@@ -269,8 +265,8 @@
2.3. Uppercase or Lowercase
- [RFC4291] does not mention about preference of uppercase or
- lowercase. Various flavors are shown below.
+ [RFC4291] does not mention any preference of uppercase or
+ lowercase.
@@ -294,40 +290,35 @@
3.1.1. General Summary
- A search of an IPv6 address if conducted through a UNIX system is
- usually case sensitive and extended options to allow for regular
- expression use will come in handy. However, there are many
- applications in the Internet today that do not provide this
- capability. When searching for an IPv6 address in such systems, the
- system engineer will have to try each and every possibility to search
+ On Unix systems while searches are generally case sensitive
+ options exist to deal with this.
+ However, there are many
+ applications on the Internet today that do not provide this
+ capability. When searching for an IPv6 address on these systems the
+ operator will have to try each and every possible representation
for an address. This has critical impacts especially when trying to
deploy IPv6 over an enterprise network.
3.1.2. Searching Spreadsheets and Text Files
- Spreadsheet applications and text editors on GUI systems, rarely have
- the ability to search for a text using regular expression. Moreover,
- there are many non-engineers (who are not aware of case sensitivity
- and regular expression use) that use these application to manage IP
- addresses. This has worked quite well with IPv4 since text
- representation in IPv4 has very little flexibility. There is no
- incentive to encourage these non-engineers to change their tool or
- learn regular expression when they decide to go dual-stack. If the
- entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was
- conducted as 2001:db8:0:0:1::1, this will show a result of no match.
- One example where this will cause problem is, when the search is
- being conducted to assign a new address from a pool, and a check was
- being done to see if it was not in use. This may cause problems to
- the end-hosts or end-users. This type of address management is very
- often seen in enterprise networks and also in ISPs.
+ Spreadsheet applications and text editors on GUI systems rarely have
+ the ability to search using regular expression. Moreover
+ there are many users that use these application to manage IP
+ addresses who are not aware of case sensitivity and regular expression
+ use.
+ These limitations have not created problems with IPv4 since text
+ representation for those addresses has very little flexibility.
+ To the extent possible non-technical users should be able to use
+ the same tools with IPv6 addresses that they are already familiar
+ with for IPv4 addresses.
3.1.3. Searching with Whois
- The "whois" utility is used by a wide range of people today. When a
- record is set to a database, one will likely check the output to see
+ The "whois" utility is used by a wide range of people today. When
+ the response is received one will likely check the output to see
if the entry is correct. If an entity was recorded as 2001:db8::/48,
but the whois output showed 2001:0db8:0000::/48, most non-engineers
- would think that their input was wrong, and will likely retry several
+ would think that their input was wrong and likely retry several
times or make a frustrated call to the database hostmaster. If there
@@ -341,31 +332,31 @@
each system showed a different text representation, this would
confuse people even more. Although this document focuses on
addresses rather than prefixes, this is worth mentioning since
- problems encountered are mostly equal.
+ the problems encountered are mostly equal.
3.1.4. Searching for an Address in a Network Diagram
- Network diagrams and blue-prints often show what IP addresses are
- assigned to a system devices. In times of trouble shooting, there
+ Network diagrams and blueprints often show what IP addresses are
+ assigned to system devices. In times of trouble shooting there
may be a need to search through a diagram to find the point of
- failure (for example, if a traceroute stopped at 2001:db8::1, one
- would search the diagram for that address). This is a technique
- quite often in use in enterprise networks and managed services.
+ failure. For example if a traceroute stopped at 2001:db8::1 one
+ would search the diagram for that address. This is a technique
+ quite often used in enterprise networks and managed services.
Again, the different flavors of text representation will result in a
- time-consuming search, leading to longer MTTR in times of trouble.
+ time-consuming search leading to longer MTTR in times of trouble.
3.2. Parsing and Modifying
3.2.1. General Summary
- With all the possible text representation ways, each application must
+ With all the possible methods of text representation each application must
include a module, object, link, etc. to a function that will parse
IPv6 addresses in a manner that no matter how it is represented, they
will mean the same address. Many system engineers who integrate
- complex computer systems to corporate customers will have
+ complex computer systems for corporate customers will have
difficulties finding that their favorite tool will not have this
function, or will encounter difficulties such as having to rewrite
- their macro's or scripts for their customers.
+ their macros or scripts for their customers.
3.2.2. Logging
@@ -373,17 +364,17 @@
address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
the output would be highly unreadable compared to the IPv4 output.
The address would have to be parsed and reformed to make it useful
- for human reading. Sometimes, logging for critical systems is done
+ for human reading. Sometimes logging for critical systems is done
by mirroring the same traffic to two different systems. Care must be
- taken that no matter what the log output is, the logs should be
+ taken so that no matter what the log output is the logs should be
parsed so they will mean the same.
3.2.3. Auditing: Case 1
When a router or any other network appliance machine configuration is
- audited, there are many methods to compare the configuration
- information of a node. Sometimes, auditing will be done by just
- comparing the changes made each day. In this case, if configuration
+ audited there are many methods to compare the configuration
+ information of a node. Sometimes auditing will be done by just
+ comparing the changes made each day. In this case if configuration
was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
@@ -395,19 +386,19 @@
0000:0000:0000:0001 just because the new engineer on the block felt
it was better, a simple diff will show that a different address was
- configured. If this was done on a wide scale network, people will be
+ configured. If this was done on a wide scale network people will be
focusing on 'why the extra zeros were put in' instead of doing any
- real auditing. Lots of tools are just plain 'diff's that do not take
+ real auditing. Lots of tools are just plain diffs that do not take
into account address representation rules.
3.2.4. Auditing: Case 2
Node configurations will be matched against an information system
- that manages IP addresses. If output notation is different, there
+ that manages IP addresses. If output notation is different there
will need to be a script that is implemented to cover for this. The
- result of an SNMP GET operation, converted to text and compared to a
+ result of an SNMP GET operation converted to text and compared to a
textual address written by a human is highly unlikely to match on
- first try.
+ the first try.
3.2.5. Verification
@@ -437,7 +428,7 @@
3.3.2. Customer Calls
- When a customer calls to inquire about a suspected outage, IPv6
+ When a customer calls to inquire about a suspected outage IPv6
address representation should be handled with care. Not all
customers are engineers nor have the same skill in IPv6 technology.
The network operations center will have to take extra steps to
@@ -456,7 +447,7 @@
3.3.3. Abuse
- Network abuse is reported along with the abusing IP address. This
+ Network abuse reports generally include the abusing IP address. This
'reporting' could take any shape or form of the flexible model. A
team that handles network abuse must be able to tell the difference
between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the
@@ -481,7 +472,7 @@
3.4.2. Preference in Documentation
- A document that is edited by more than one author, may become harder
+ A document that is edited by more than one author may become harder
to read.
3.4.3. Legibility
@@ -494,7 +485,7 @@
A recommendation for a canonical text representation format of IPv6
addresses is presented in this section. The recommendation in this
- document is one that, complies fully with [RFC4291], is implemented
+ document is one that: complies fully with [RFC4291], is implemented
by various operating systems, and is human friendly. The
recommendation in this section SHOULD be followed by systems when
@@ -508,7 +499,7 @@
generating an address to represent as text, but all implementations
MUST accept and be able to handle any legitimate [RFC4291] format.
It is advised that humans also follow these recommendations when
- spelling an address.
+ writing an address.
4.1. Handling Leading Zeros in a 16 Bit Field
@@ -520,7 +511,7 @@
4.2.1. Shorten As Much As Possible
- The use of symbol "::" MUST be used to its maximum capability. For
+ When used the "::" symbol MUST be used to its maximum capability. For
example, 2001:db8::0:1 is not acceptable, because the symbol "::"
could have been used to produce a shorter representation 2001:db8::1.
@@ -540,6 +531,15 @@
bits MUST be shortened. For example 2001:db8::1:0:0:1 is correct
representation.
+4.2.4. Exception to the "::" Shortening Rule
+
+ When it is necessary to record an address with consecutive 16 bit 0
+ fields without the use of the "::" symbol, for example in a database,
+ each such field SHOULD be represented with one, and only one zero. For
+ example 2001:db8:0:0:0:0:0:1. However when the address is written out
+ for human consumption the "::" MUST be used as described in the sections
+ above.
+
4.3. Lower Case
The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST
@@ -587,8 +587,7 @@
6. Notes on Combining IPv6 Addresses with Port Numbers
When IPv6 addresses and port numbers are represented in text combined
- together, there are many different ways to do so. Examples are shown
- below.
+ together, there are many different ways to do so.
o [2001:db8::1]:80
@@ -602,8 +601,8 @@
o 2001:db8::1#80
- The situation is not much different in IPv4, but the most ambiguous
- case with IPv6 is the second bullet. This is due to the "::"usage in
+ The situation is not much different from IPv4 but the most ambiguous
+ case with IPv6 is the second bullet. This is due to the "::" usage in
IPv6 addresses. This style is NOT RECOMMENDED for its ambiguity.
The [] style as expressed in [RFC3986] SHOULD be employed, and is the
default unless otherwise specified. Other styles are acceptable when
@@ -623,13 +622,13 @@
7. Prefix Representation
Problems with prefixes are just the same as problems encountered with
- addresses. Text representation method of IPv6 prefixes should be no
+ addresses. The text representation method for IPv6 prefixes should be no
different from that of IPv6 addresses.
8. Security Considerations
- This document notes on some examples where IPv6 addresses are
+ This document notes some examples where IPv6 addresses are
compared in text format. The example on Section 3.2.5 is one that
may cause a security risk if used for access control. The common
practice of comparing X.509 data is done in binary format.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
