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

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

Hi Gunter,

Responses in line. 

> 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. 
> <>

Yes.

> 
> > 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.  
> <>

Yes.

> 
> 
> > 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:
> <>

Yes.

> 
> 
> 
> >  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?

What I am asking is if there is global part of prefix prior to 16 bits
of subnetting that can be aggregated on an Intranet.  ULA Global ID
48bits and Subnet 16 bits then the 48bits can be aggregated.

> 
> 
> > 
> > 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.  
> <>

Yes.

> 
> > 
> >  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.  
> <>

Yes.

Just as a note I have not parsed all this in my mind yet but imagine a
DSL or Cable provider parsing our 64bit prefixes as a norm for homes,
cars, etc then 2^64 is not that large in my view if we view global
deployment across the earth.  I am just concerned that we be careful
with address space conservation how we use the 2^64 prefixes too.

> 
> 
> > 
> >  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.

Your right but an implementation may slice up that 64bits the entire
effort to support virtualized guest operating systems on one node for
networking is still under work and I would think SLAAC can be used for
these virtual OS implementations.  Plus it is addressed below.

> 
> > 
> > 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.
> <>

Yes just want the note.

> 
> > 
> >  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):

Could point on point-to-point.

> 
> <>
>    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.
> <>

Excellent nice job on that text. We can use this in other specs I think
as it comes up.

> 
> 
> 
> > 
> > 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.
> <>

Excellent and again we can use that in other specs and discussions in
IETF too.

> 
> > 
> > 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/

I am more concerned about adding notation to the spec about any
transition mechanisms as part of an addressing plan, it adds potentially
questions on use and that should be a separate IETF spec other than the
scenarios done already by v6ops.  On second thought it does no harm and
my issue of overloading the addcon spec with potential support to any
transition mechanism, but yes stating it is Experimental is important.

> > 
> > 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

OK.

> 
> > 
> > 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]
> <>

Perfect it makes no statement with this fix pro or con which was my
point. 

> 
> 
> 
> > 
> > 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. 

OK we need to discuss then it really has not much to do with an
addressing plan.

> 
> 
> > 
> > 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

ACK.

> 
> > 
> > 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

OK my error I was viewing this note for the entire 128bits.

> 
> > 
> > 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

By being in appendix it fast tracks the spec to PS faster or
Informational. For example if an appendix I have no comment on the use
cases other than generally speaking as its the authors choice to
identify the strategy for a use case.  I just think putting this in
appendix reduces our work here avoids the IESG from having to verify in
the use case IETF requirements are met more strictly.  I like the use
cases as a note.

> 
> 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. 

OK thanks for your quick response too appreciate you and your co-authors
work on this it is important.

Thanks
/jim

> 
> Best,
> /jim 
>