[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-v6ops-addcon-03.txt
Thanks again for your valued feedback. Many have triggered a proposed
rewrite of text. Let me know what you think about it.
See Inline: look for GV>
Note: I'm not sure what to do with the ISATAP comments. The draft is not
proposing to use ISATAP, but is just telling that using an address that
looks like an ISATAP one is maybe not very smart. I will await for the
WG to suggest what to do next with those comments.
-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Wednesday, April 04, 2007 9:30 PM
To: Gunter Van de Velde (gvandeve); Brian E Carpenter; Bonness, Olaf
Cc: v6ops@ops.ietf.org
Subject: RE: I-D ACTION:draft-ietf-v6ops-addcon-03.txt
Gunter,
Just found out I have been extracted in next few days on day job so did
this right away to get it to the list.
> From 2.2
>
> The usage of ULAs should be carefully considered even when notattached
> to the IPv6 Internet due to the potential for added complexity when
> connecting to the Internet at some point in the future.
>
Technically the above is a non issue. You say it is complex but give no
technical example. Suggest you identify just in bullets the problems. I
think this is important especially when users, or Enterprises require
global connectivity.
GV> Would following section re-write be acceptable?
<>
The usage of ULAs should be carefully considered even when not
attached to the IPv6 Internet as some IPv6 specifications were
created before the existence of ULA addresses.
<>
> 2.4. Network Level Design Considerations
>
> IPv6 provides network administrators with a significantly larger
> address space, enabling them to be very creative in how they can
> define logical and practical address plans. The subnetting of
> assigned prefixes can be done based on various logical schemes that
> involve factors such as:
> o Geographical Boundaries - by assigning a common prefix to all
> subnets within a geographical area
> o Organizational Boundaries - by assigning a common prefix to an
> entire organization or group within a corporate infrastructure
> o Service Type - by reserving certain prefixes for predefined
> services such as: VoIP, Content Distribution, wireless services,
> Internet Access, etc
>
Service Type addresses is not a good way to identify services and can
create many dependencies on IP addresses that can make renumbering even
harder if the nodes or interfaces supporting those services on the
network are sparse within the topology. Suggest this in some form be
noted. Or remove the Service Type.
GV> Would following section re-write be acceptable?
<>
o Service Type - by reserving certain prefixes for predefined
services such as: VoIP, Content Distribution, wireless services,
Internet Access, etc. This type of addressing may create
dependencies
on IP addresses that can make renumbering harder if the
nodes or interfaces supporting those services on the network
are sparse within the topology.
<>
> The network designer must however keep in mind several factors when
> developing these new addressing schemes:
> o Prefix Aggregation - The larger IPv6 addresses can lead to
> larger
> routing tables unless network designers are actively pursuing
> aggregation. While prefix aggregation will be enforced by the
> service provider, it is beneficial for the individual
> organizations to observe the same principles in their network
> design process
>
As the document is speaking about multiple address forms be good to
identify up front in section 2 or somewhere this case is for global.
Though it could be issue for Intranet too.
GV> Proposed rewrite
<>
The network designer must however keep in mind several factors when
developing these new addressing schemes for networks with and
without global connectivity:
<>
> o ULA usage in large networks - Networks which have a large number
> of 'sites' that each deploy a ULA prefix which will by default
> be
> a 'random' /48 under fc00::/7 will have no aggregation of those
> prefixes. Thus the end result may be cumbersome because the
> network will have large amounts of non-aggregated ULA prefixes.
> However, there is no rule to disallow large networks to use a
> single ULA for all 'sites', as a ULA still provides 16 bits for
> subnetting to be used internally
>
But the Global ID if subnets are less then 2^^16 can be aggregated with
ULAs.
GV> I'm not sure I understand this comment?
>
> 3.1. Considerations for subnet prefixes shorter then /64
>
> An allocation of a prefix shorter then 64 bits to a node or
> interface
> is considered bad practice. The shortest subnet prefix that could
> theoretically be assigned to an interface or node is limited by the
> size of the network prefix allocated to the organization. One
> exception to this recommendation is when using 6to4 technology
> where
> a /16 prefix is utilised for the pseudo-interface [8].
>
I don't see how 6to4 obviates the shortest subnet prefix statement made.
GV> This line was added by a comment from Pekka I believe. It was
mentioned that
6to4 uses 2002::/16 configuration on an interface and is not bad
practice.
It looks like the base text is not clear and raises confusion. Would
following re-write be more clear.
<>
An allocation of a prefix shorter then 64 bits to a node or interface
is considered bad practice. One exception to this statement is
when using 6to4 technology where a /16 prefix is utilised for
the pseudo-interface [8]. The shortest subnet prefix that could
theoretically be assigned to an interface or node is limited by the
size of the network prefix allocated to the organization.
<>
>
> A possible reason for choosing the subnet prefix for an interface
> shorter then /64 is that it would allow more nodes to be attached
> to
> that interface compared to a prescribed length of 64 bits. This
> however is unnecessary considering that 2^64 provides plenty of
> node
> addresses for a well designed IPv6 network. Layer two technologies
> are unlikely to support such large numbers of nodes within a single
> link (e.g. Ethernet limited to 48-bits of hosts)
>
I don't agree with the above assumption for sensor networks as one case.
Also I don't see the relation made between link waveform media and IP
addresses and it is orthogonal.
GV> What about following rewrite. Does it take the implied assumption
away?
<>
A possible reason for choosing the subnet prefix for an interface
shorter then /64 is that it would allow more nodes to be attached
to that interface compared to a prescribed length of 64 bits. This
however is unnecessary for most networks considering that 2^64
provides
plenty of node addresses.
<>
>
> The subnet prefix assignments can be made either by manual
> configuration, by a stateful Host Configuration Protocol [11] or by
> a
> stateful prefix delegation mechanism [16].
>
Or implied by stateless autoconfiguration from prefix RAs.
GV> Does this exist? I assumed that only SLAAC with 64 bit prefix length
existed.
>
> 3.2. Considerations for /64 prefixes
>
> Based on RFC3177 [9], 64 bits is the prescribed subnet prefix
> length
> to allocate to interfaces and nodes.
>
> When using a /64 subnet length, the address assignment for these
> addresses can be made either by manual configuration, by a stateful
> Host Configuration Protocol [11] [18] or by stateless
> autoconfiguration [2].
>
> Note that RFC3177 strongly prescribes 64 bit subnets for general
> usage, and that stateless autoconfiguration option is only defined
> for 64 bit subnets.
>
True but end node configurations are permitted to view the prefix bits
they want if required such as guest OSs by a Hypervisor. I agree with
the RFC 3177 recommendation but I believe this document should expose
other deployment implementation options can be used.
GV> Can I assume that this what you were aleviating at in the above
comment?
what about following rewrite
<>
Note that RFC3177 strongly prescribes 64 bit subnets for general
usage, and that stateless autoconfiguration option is only defined
for 64 bit subnets. However, implementations could use proprietary
mechanism
for stateless autoconfiguration for different then 64 bit prefix
length.
<>
>
> When using subnet lengths longer then 64 bits, it is important to
> avoid selecting addresses that may have a predefined use and could
> confuse IPv6 protocol stacks. The alternate usage may not be a
> simple unicast address in all cases. The following points should
> be
> considered when selecting a subnet length longer then 64 bits.
>
I think the document should take hard stand and say never permit >
64bits for current specified address architecture.
GV> I'm not sure about that hard stand as there are real deployments out
there with >64 prefix lengths, mainly on point2point links though.
Whould following note in the text help? (it is not as strong as your
suggested hard stand):
<>
Address space conservation is the main motivation for using a subnet
prefix length longer than 64 bits, however this kind of address
conservation is of futile benefit compared with the additional
considerations one must make when creating and maintain an IPv6
address plan.
<>
>
> 3.3.1. Anycast addresses
>
> It is recommended to avoid allocating this IPv6 address to a device
> which is not a router. No additional dependencies for the subnet
> prefix while the EUI-64 and an IID dependencies will be discussed
> later in this document.
>
I would suggest that anycast just for a router stated is a bit harsh for
an address use document. For example a node that performs routing could
also be a load balancer function to provide multi-pathing to other
nodes. A bit more than a router.
GV> ack. What about following re-write
<>
It is recommended to avoid allocating this IPv6 address to an
device
which expects to have a normal unicast address. No additional
dependencies
for the subnet prefix while the EUI-64 and an IID dependencies will
be discussed later in this document.
<>
>
> 3.3.3. ISATAP addresses
>
This is an IETF Experimental RFC and should not be part of this spec and
if it is kept requires health warnings that this spec was not accepted
as a Proposed Standard. But I do not see the point of adding Section
3.3.3 it is an IPv6 Transition issue. In addition there is precedence
within the IESG to not declare non proposed standard transition
mechanisms in our v6ops specs. It also assumes a wide deployed IPv4
multicast network and that is not the norm either and we should not add
new IPv4 requirements where they don't exist for IPv6 when possible.
GV> The doc does not suggest using ISATAP. It just mentiones that it
doesn't quantify great intelligence to assign an address that looks like
an ISATAP address
when only a normal unicast address is expected.
I could do s/an automatic tunneling/an experimental automatic tunneling/
>
> When choosing a 128 bit prefix, it is recommended to take the "u" and
> "g" bits into consideration and to make sure that there is no
> overlap
> with either the following well-known addresses:
> o Subnet Router Anycast Address
> o Reserved Subnet Anycast Address
> o Addresses used by Embedded-RP
> o ISATAP Addresses
>
Remove ISATAP per the above.
GV> I will let the WG decide on that
>
> 4.2. Using Privacy Extensions
>
> The main purpose of IIDs generated based on RFC3041 [6] is to
> provide
> privacy to the entity using this address. While there are no
> particular constraints in the usage of these addresses as defined
> in
> [6] there are some implications to be aware of when using privacy
> addresses as documented in section 4 of RFC3041 [6]:
> o The privacy extension algorithm may complicate flexibility in
> future transport protocols
> o These addresses may add complexity to the operational management
> and troubleshooting of the infrastructure (i.e. which address
> belongs to which real host)
> o A reverse DNS lookup check may be broken when using privacy
> extensions
>
The document needs to identify all the advantages of 3041 too not just
"potential" issues. I don't agree with the above technical networking
administrative problems if the network performs the correct operations
to avoid such chaos. Many customers I work with require 3041 as note.
GV> So you would propose a more balanced view? Or maybe even remove the
three bullets and just reference the implications by a reference? Would
the following section be ok? (I just removed the three bullets)
<>
4.2. Using Privacy Extensions
The main purpose of IIDs generated based on RFC3041 [6] is to provide
privacy to the entity using this address. While there are no
particular constraints in the usage of these addresses as defined in
[6] there are some implications to be aware of when using privacy
addresses as documented in section 4 of RFC3041 [6]
<>
>
> 4.3. Cryptographically Generated IPv6 Addresses
>
I do not see the point of 4.3 at all for this document. There are other
means to accomplish what is required by them on an IPv6 network and CGA
has not been widely deployed needs to be stated if this is to remain but
I really cannot support putting this in the document.
GV> I'm ok to remove this section if the WG agrees.
>
> In this situation the actual allocation is done by human intervention
> and consideration needs to be given to the complete IPv6 address so
> that it does not result in overlaps with any of the well known IPv6
> addresses:
> o Subnet Router Anycast Address
> o Reserved Subnet Anycast Address
> o Addresses used by Embedded-RP
> o ISATAP Addresses
>
Remove ISATAP
GV> see before
>
> When using an address assigned by human intervention it is
> recommended to choose IPv6 addresses which are not obvious to guess
> and/or avoid any IPv6 addresses that embed IPv4 addresses used in
> the
> current infrastructure. Following these two recommendations will
> make it more difficult for malicious third parties to guess targets
> for attack, and thus reduce security threats to a certain extent.
>
Then 6to4 needs to be noted as you referenced it previously.
GV> I'm not sure I understand the comment? 6to4 puts the IPv4 address in
the prefix, not the IID
>
> 5. Case Studies
I take back my comment on DHCPv6 it is in the context of a use case. But
suggest that the use cases become appendices or label them that these
are test cases and reflect no standard and a conceptual model for the
purposes of this document. And DHCPv6 is being deployed on other test
networks and planned to be used by production networks with customers I
work with in industry.
GV> It was one of the questions when I presented this draft at IETF68.
Should we leave the case-studies in body of the text, or move them to
the appendix. There was no real agreement yet. The editors feel that
there is use for the examples given, but have no strong objection to
move it into the appendix area
As I said the main theme of the document is done well and written well,
but it is the off topics in my view that cause me pain and push
assumptions to future readers I do not find fair when so many others are
missing.
GV> Thanks for your review and comments. I proposed rewrites for most of
your suggestions. With ISATAP I will leave it to the WG to decide if its
in or out.
Best,
/jim