RE: I-D ACTION:draft-ietf-v6ops-addcon-03.txt

["Bound, Jim" <Jim.Bound@hp.com>]

thank you Gunter I will respond if required over the weekend cannot
right now and if all set will say that too.

/jim 

> -----Original Message-----
> From: Gunter Van de Velde (gvandeve) [mailto:gvandeve@cisco.com] 
> Sent: Thursday, April 05, 2007 5:15 AM
> To: Bound, Jim; Brian E Carpenter; Bonness, Olaf
> Cc: v6ops@ops.ietf.org
> Subject: 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 
>