[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
> 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.
> 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.
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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
>
> 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.
>
> 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.
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.
Best,
/jim