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

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Apr 2007 16:09:31 +0200

Some of my earlier comments haven't resulted in any text changes.
I'm not completely at ease about these points.

On 2006-06-13 09:25, Brian E Carpenter wrote:
...
>> 2.2.  Unique Local IPv6 Addresses
> ...
>>    Because a ULA and a global site prefix are both /48 length, an
>>    administrator can choose to use the same subnetting (and host
>>    addressing) plan for both prefixes.
> 
> The RIRs are moving away from a rigid /48 policy. It would be safer
> to start this sentence with "When" instead of "Because".
> And on the same topic...
> 
>> 2.4.  Network Level Design Considerations
> 
> I suggest adding a bullet at the end of this section along these
> lines:
> 
> o It is possible that as registry policies evolve, a small site
>   may experience an increase in prefix length when renumbering,
>   e.g. from /48 to /56. For this reason, the best practice is
>   number subnets compactly rather than sparsely, and to
>   use low-order bits as much as possible when numbering subnets.
>   In other words, even if a /48 is allocated, act as though
>   only a /56 is available. Clearly, this advice does not apply
>   to large sites and enterprises that have an intrinsic need
>   for a /48 prefix.

On 2006-07-19 17:37, Brian E Carpenter wrote:
...
>> 2.4.2.  Address Space Conservation
>>
>>    Despite the large IPv6 address space which enables easier subnetting,
>>    it still is important to ensure an efficient use of this resource.
>>    Some addressing schemes, while facilitating aggregation and
>>    management, could lead to significant numbers of addresses being
>>    unused.  Address conservation requirements are less stringent in IPv6
>>    but they should still be observed.
>>
>>    The proposed HD [8] value for IPv6 is 0.94 compared to the current
>>    value of 0.96 for IPv4.  Note that for IPv6 HD is calculated for
>>    sites (i.e. on a basis of /48), instead of based on addresses like
>>    with IPv4.
> 
> Perhaps it would be wiser to make the parenthesis
>      (e.g. on a basis of /48)
> 
> Thanks for adding the ISP case. Some comments...
> 
>> 5.2.1.2.  IPv6 addressing schema requirements from the ISP perspective
>>           of the Service Provider
>>
>>    From ISP perspective the following basic requirements could be
>>    identified:
>>    o  The IPv6 address allocation schema must be able to realize a
>>       maximal aggregation of all IPv6 address delegations to customers
>>       into the /20 of the Service Provider.  Only this /20 will be
>>       routed and injected from the Service Provider into the global
>>       routing table (DFZ).  This strong aggregation keeps the routing
>>       tables of the DFZ small and eases filtering and access control
>>       very much.  (Note: A strong aggregation e.g. on POP or LER basis
>>       limits as well the numbers of customer routes that are visible
>>       within the ISP network.)
> 
> I'm quite concerned by this. Basically, why? Are we really expecting
> ISPs to have so many customer sites that they can't simply flat-route
> internally? Yes, that may be slightly less attractive for an MPLS
> based ISP rather than for one using IP routing, but it has horrible
> consequences because of the way it constrains address assignment.
> 
>> 5.2.1.3.  IPv6 addressing schema requirements from the Network Access
>>           provider perspective of the Service Provider
>>
>>    As already done for the LIR and the ISP roles of the SP it is also
>>    necessary to identify requirements that come from its Network Access
>>    Provider role.  Some of the basic requirements are:
>>    o  The IPv6 addressing schema of the SP must be flexible enough to
>>       adapt changes that are injected from the customer side.  This
>>       covers changes that are based on the raising IPv6 address needs of
>>       the customer as well as changes that come from topological
>>       modifications (e.g. when the customer moves from one point of
>>       network attachment (POP) to another).
> 
> I don't understand "changes that are injected from the customer side."
> Does this mean injected by a routing protocol? What sort of flexibility
> do you mean? And when a customer changes POP, well, see my previous
> comment. That should just be a routing change.

There was a little discussion following my comments, and I hoped for
a few clarifying sentences in the document.

     Brian

---

From: "Bonness, Olaf" <[email-masked]>
Date: Tue, 3 Apr 2007 18:32:41 +0200

Hi Brian,

Thank you very much for your remarks. I'll target in my answer only to your remarks regarding chapter 5 issues and leave the answers for the other points to my editor colleagues. Besides that I'll attach (parts of) my email reply from 20th of July 2006 at the end of my email.

Section 5.2.1.2
Brian, if you compare the old section 5.2.1.2 from addcon_01 with the actualized section 5.2.1.2 from addcon_v03 than you can observe several changes, we've injected based on our email discussion. 
For instance we've added the note within the third bullet point of 5.2.1.2 where it is stated that each aggregation level brings down the efficiency of the addressing schema and that each ISP has to decide how many levels of aggregation it wants to implement. For a better understanding I can extend this to a statement where small ISPs may even implement a flat addressing architecture without any internal aggregation level.
(But from my point of view the vast majority of ISPs will have to have at least one level of address aggregation since it is no fun to have all the 100.000's / millions of customer routes inside your internal routing tables. So flat routing will IMHO be the exception and not the rule.)

Section 5.2.1.3
Regarding your comments to section 5.2.1.3 we've modified the wording of (the first bullet point of) this section and restructured chapter 5 of the ID by explicitely discussing "Changing Point of Network Attachement" in section 5.2.3.4. Perhaps a pointer to this section in 5.2.1.3 would be helpful and I'll insert it.

I hope that this will help to eliminate the obscurenesses you mentioned and will make the ID more readable.
Thanks again for your suggestions and best regards
	Olaf

====> Olaf Bonness wrote on 2006-07-20 <============================================
....
> 5.2.1.2.
 
The described example illustrates an addressing plan of an ISP who offers its service to several millions of customers. Thats why it is very needed to have some kind of aggregation level for the IPv6 aggregates of the customers - because of the number of routing table entries as well as (for an MPLS-based ISP) because of MPLS-Label space conservation.
Very small ISPs may perhaps implement a flat routing, but it is IMHO nevertheless recommended to think about an aggregation level since 150.000 routes are 150.000 routes and need a certain amount of (expensive) routing power to be handled.

Yes we've observed as well that every level of hierarchy will bring down the efficiency of the addressing schema. Thats why it is necessary for the ISP to find the right trade-off between address space conservation and routing table size. I.e. again 'No "One size fits all"'.
(IMHO in most cases one aggregation level should be enough.)

.....
> 5.2.1.3

By "changes from customer side" we meant all impacts to the addressing and routing topology of the ISP that are triggered by the customer wishes. This covers for instance:
- Larger address aggregate needs (covered by the "growing zones" reserved for the customer aggregates)
- Changing the point of attachement of the customer to the provider network (that leads to more specific routes, if some kind of address aggregation schema has been implemented). 
Whereas the first point is a clear topic for the address allocation schema - the second one has most likely to be handled by the routing infrastructure. But by choosing a "clever" address aggregation schema - the number of additional routes can be limited in one or the other case.

.....
=================================> End <============================================

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 4:10 PM
To: IPv6 Operations
Subject: Re: I-D ACTION:draft-ietf-v6ops-addcon-03.txt

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Apr 2007 13:48:26 +0200

> (But from my point of view the vast majority of ISPs will have to have at least one level of address aggregation since it is no fun to have all the 100.000's / millions of customer routes inside yo…

OK, somehow the diff I ran didn't make me look at that.
I agree it's better. I think it might be worth adding that since
IPv6 space is not as precious as IPv4 space, the tradeoff may
be different than it was for IPv4.

> Regarding your comments to section 5.2.1.3 we've modified the wording of (the first bullet point of) this section and restructured chapter 5 of the ID by explicitely discussing "Changing Point of N…

I still think you need to be more clear what "injected" means and what flexibility
is needed. "Injected" to me means injected automatically by a routing protocol,
unless you say that it means a change in the customer's SLA, which I
understand from your explanation. And I think "flexibility" means updating
some configuration files, not responding automatically to a routing
update?

       Brian

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 4 Apr 2007 10:58:14 -0400

I cannot support this spec moving forward without major changes to its
content I will provide more by tomorrow but here is major heartburn for
me.

- Remove any mention of ISATAP this is not relative to the point of the
spec.

- Remove discussion of CGA this is not relative to the point of the
spec.

- Do not make statements about what the market is doing such as the
DHCPv6 statements because we cannot possibly represent all input from
the market within an IETF spec. And you say use CGA which has clearly
only research deployment where as DHCPv6 is far more deployed yet you do
not say CGA is unknown. Sounds like a bias to me.

I found other technical bugs and will get them out in a few days.

But this is not ready for the IESG or as spec that has consensus per the
V6OPS charter in my view.  

The ULA, PI, PA and that type of recommendations are very good and that
is what the spec should stick too.

/jim

---

From: "Gunter Van de Velde \(gvandeve\)" <[email-masked]>
Date: Wed, 4 Apr 2007 18:09:14 +0200

Jim,

Thanks, we will be looking forward to your feedback, and we hope to get
an update 
on the technical bugs implied. It is exactly the reason of creating this
draft 
as not all readers will have expertice of all created RFC's and drafts 
about IPv6 of last few years.

As far i am aware we don't suggest or imply using ISATAP, CGA or
anything 
else... Master plan is to describe known considerations when creating 
an address plan as the title implies.

Thanks again for you time to read/study the document and provide
feedback

Groetjes,
G/ 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bound, Jim
Sent: Wednesday, April 04, 2007 4:58 PM
To: Brian E Carpenter; Bonness, Olaf
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-v6ops-addcon-03.txt

/jim

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 4 Apr 2007 10:28:28 -0700

Hi Jim,

> - Remove any mention of ISATAP this is not relative to the 

I just took a look at the spec for the first time. I agree
with the inclusion of Section 3.3.3 but I'm ambivalent on
the inclusion of the paragraph beginning: "When using subnet
prefix length...".

Reason being is that the ISATAP interface identifier format
only applies for addresses assigned on ISATAP interfaces,
so the fact that an address assigned on some other type of
interface resembles an ISATAP address may be irrelevant.

I'd like to hear other opinions on this, however.

Thanks - Fred
[email-masked]

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 4 Apr 2007 15:29:33 -0400

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.

>    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

---

From: "Bonness, Olaf" <[email-masked]>
Date: Thu, 5 Apr 2007 10:09:51 +0200

Hi Brian

Tnx for your reply. Just a few remarks inline. 

> Sent: Wednesday, April 04, 2007 1:48 PM
> To: Bonneß, Olaf
> Cc: [email-masked]
> > Thank you very much for your remarks. I'll target in my 
> answer only to your remarks regarding chapter 5 issues and 
> leave the answers for the other points to my editor 
> colleagues. Besides that I'll attach (parts of) my email 
> reply from 20th of July 2006 at the end of my email.
> > 
> > Section 5.2.1.2
> > Brian, if you compare the old section 5.2.1.2 from 
> addcon_01 with the actualized section 5.2.1.2 from addcon_v03 
> than you can observe several changes, we've injected based on 
> our email discussion. 
> > For instance we've added the note within the third bullet 
> point of 5.2.1.2 where it is stated that each aggregation 
> level brings down the efficiency of the addressing schema and 
> that each ISP has to decide how many levels of aggregation it 
> wants to implement. For a better understanding I can extend 
> this to a statement where small ISPs may even implement a 
> flat addressing architecture without any internal aggregation level.
> > (But from my point of view the vast majority of ISPs will 
> have to have at least one level of address aggregation since 
> it is no fun to have all the 100.000's / millions of customer 
> routes inside your internal routing tables. So flat routing 
> will IMHO be the exception and not the rule.)
> 

0 problemo.
I'll add than your remark that small ISPs could chose flat addressing architectures without internal levels of address aggregation to our next version of the addcon ID.

> 
> > 
> > Section 5.2.1.3
> > Regarding your comments to section 5.2.1.3 we've modified 
> > the wording of (the first bullet point of) this section and 
> > restructured chapter 5 of the ID by explicitely discussing 
> > "Changing Point of Network Attachement" in section 5.2.3.4. 
> > Perhaps a pointer to this section in 5.2.1.3 would be helpful 
> > and I'll insert it.
> 

O.k. I see your problem. I'll try to find a better formulation, since "inject" and "flexibility" are indeed a bit misleading:

	5.2.1.3
	...
	The IPv6 addressing schema of the SP must be chosen in a way that it 
      can handle new requirements that are triggered from customer side.
	This can be for instance the growing needs of the customers regarding 
	IPv6 addresses as well as customer driven modifications within the 
	access network topology (e.g. when the customer moves from one point 
	of network attachment (POP) to another). 
	(See also section 5.2.3.4 "Changing Point of Network Attachement")

Does this the trick? Perhaps it would be very helpful if you could propose a more "English" version of this idea since I'm not a native speaker :).
 
Tnx and regards
	Olaf

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Apr 2007 10:27:26 +0200

below...

> Does this the trick? Perhaps it would be very helpful if you could propose a more "English" version of this idea since I'm not a native speaker :).

That's fine. I'm sure the RFC Editor will fix any little syntax
details. Thanks!

     Brian

---

From: "Gunter Van de Velde \(gvandeve\)" <[email-masked]>
Date: Thu, 5 Apr 2007 11:15:10 +0200

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:[email-masked]] 
Sent: Wednesday, April 04, 2007 9:30 PM
To: Gunter Van de Velde (gvandeve); Brian E Carpenter; Bonness, Olaf
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-v6ops-addcon-03.txt

Gunter,

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

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

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

>    o  Prefix Aggregation - The larger IPv6 addresses can lead to 
> larger

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

>       of 'sites' that each deploy a ULA prefix which will by default 
> be

GV> I'm not sure I understand this comment?

>    An allocation of a prefix shorter then 64 bits to a node or 
> interface
>    exception to this recommendation is when using 6to4 technology 
> where

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

>    shorter then /64 is that it would allow more nodes to be attached 
> to
>    however is unnecessary considering that 2^64 provides plenty of 
> node

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

>    configuration, by a stateful Host Configuration Protocol [11] or by

> a

GV> Does this exist? I assumed that only SLAAC with 64 bit prefix length
existed.

>    Based on RFC3177 [9], 64 bits is the prescribed subnet prefix 
> length

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

>    simple unicast address in all cases.  The following points should 
> be

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

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

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/

>    "g" bits into consideration and to make sure that there is no 
> overlap

GV> I will let the WG decide on that

>    The main purpose of IIDs generated based on RFC3041 [6] is to 
> provide
>    particular constraints in the usage of these addresses as defined 
> in

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)

<>

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

GV> I'm ok to remove this section if the WG agrees. 

Remove ISATAP

GV> see before

>    and/or avoid any IPv6 addresses that embed IPv4 addresses used in 
> the

GV> I'm not sure I understand the comment? 6to4 puts the IPv4 address in
the prefix, not the IID

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

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Apr 2007 08:57:22 -0700

Jim,

> as a Proposed Standard.

You know I respect you, and that goes way back to when I was
hearing good things about you from the folks at LTN, LJO and
BXB before you arrived at ZKO. But, let's quit pretending about
this; ISATAP is in widely-deployed implementations and is useful
for automatic tunneling within sites both large and small, both
static and mobile, and both managed and ad-hoc. In fact, I was
demonstrating ISATAP in MANETs in 2000/2001, and I know that
the predecessors of ISATAP were demonstrated long before that.

About standards-track for ISATAP, that is long overdue, and
we are working to fix that as we speak.

About health warnings, if there were anything unhealthy about
ISATAP we would have heard about it long before now. I think
it's high time we deem this "experiment" a success, declare
victory and move on.

Based on what I saw in Prague, IMHO we are doing a new breed
of Internet engineers a disservice by leading them to believe
there is still a problem to be solved when we already have
the solution at hand.  

> But I do not see the point of adding Section
> 3.3.3 it is an IPv6 Transition issue.

1,$ s/transition/coexistence/g

> In addition there is precedence
> mechanisms in our v6ops specs.

We already have a specification for the use of embedded IPv4
addresses in the IETF OUI of "00-00-5e" and I don't see that
going away; "ISATAP addresses" is just a convenient and
well-recognized way to call them. 

> It also assumes a wide deployed IPv4

About multicast, I think you have this mixed up with RFC2529
which is more or less superceded by ISATAP.

Thanks - Fred

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 5 Apr 2007 12:27:18 -0400

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

/jim 

> From: Gunter Van de Velde (gvandeve) [mailto:[email-masked]] 
> Sent: Thursday, April 05, 2007 5:15 AM
> To: Bound, Jim; Brian E Carpenter; Bonness, Olaf
> Cc: [email-masked]
> 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.
> 
> 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
> > 
> notattached
> 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.
> 
> 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.
> 
>        Internet Access, etc. This type of addressing may 
> create dependencies 
> 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.
> But the Global ID if subnets are less then 2^^16 can be 
> aggregated with ULAs.
> 
> 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.
> 
> <>
> attached 
> Also I don't see the relation made between link waveform 
> media and IP addresses and it is orthogonal.
> 
>   however is unnecessary for most networks considering that 
> 2^64 provides
> [11] or by
> 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.
> 
>     for 64 bit subnets. However, implementations could use 
> proprietary mechanism 
>     for stateless autoconfiguration for different then 64 bit 
> prefix length.
> <>
> 
> > 
> I think the document should take hard stand and say never 
> permit > 64bits for current specified address architecture.
> 
> Whould following note in the text help? (it is not as strong 
> as your suggested hard stand):
> 
> <>
> 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.
> 
>      It is recommended to avoid allocating this IPv6 address 
> to an device
>      which expects to have a normal unicast address.  No 
> additional dependencies 
> 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.
> 
> 
> doesn't quantify great intelligence to assign an address that 
> looks like an ISATAP address when only a normal unicast 
> address is expected.

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 5 Apr 2007 12:34:40 -0400

Fred,

I will respond respectfully this weekend I cannot right now thanks for
the response good to get your input discussed  from my input to addcon.
One quick comment is things have changed in some markets since those old
days and that is IPv6 dominant deployment in the world we worked in you
describe below thus ISATAP is not seen as advantage and is asked not to
be used today. This all goes back to killing the NGNTRANS group which
was years ago IMHO I have always supported ISATAP as vehicle for
transition but the IETF sees it different the only reason 6to4 is PS
IMHO is because it came in under the radar before the new views on
transition mechanisms, and note 6to4 is also declared to not be used by
that market we worked in today either.  And as always this is business
not personal and I know you know that.

Best,
/jim 

> From: Templin, Fred L [mailto:[email-masked]] 
> Sent: Thursday, April 05, 2007 11:57 AM
> To: Bound, Jim
> Cc: [email-masked]
> this spec 
> > and if it is kept requires health warnings that this spec was not 
> > accepted as a Proposed Standard.
> 
> BXB before you arrived at ZKO. But, let's quit pretending 
> about this; ISATAP is in widely-deployed implementations and 
> is useful for automatic tunneling within sites both large and 
> small, both static and mobile, and both managed and ad-hoc. 
> In fact, I was demonstrating ISATAP in MANETs in 2000/2001, 
> and I know that the predecessors of ISATAP were demonstrated 
> long before that.
> 
> > 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.
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 7 Apr 2007 11:31:26 -0400

Fred,

Responses in line. 

> and I know that the predecessors of ISATAP were demonstrated 

I did not say for the purposes of addcon it is not a widely implemented
transition mechansism. ISATAP as 6to4 are widely implemented.  But, I do
not agree that ISATAP or 6to4 are so widely deployed that they warrant
an interface identification note within addcon specification.  If addcon
wants to add a section to discuss transition interfaces it needs to add
these I agree but then there others that must be added for VPNs and
Tunneling semantics.

> we are working to fix that as we speak.

I have no comment at this time for this mail thread on that topic.  But,
I have had experience in the IETF recently where the norm is for the
IESG to not support references that state IETF support or imply that
support for Experimental RFCs.  If that is not the case then that would
be good to know for me.

> it's high time we deem this "experiment" a success, declare 

Anytime a node tunnels packets to support a virtualized state such as
ISATAP does to support neighbor discovery has notes that should be
stated.  That is what I mean by health warnings.  For example nodes
should not be using this mechanism to subvert the addressing policy and
use of IPv6 communications without be authorized, etc.  

> there is still a problem to be solved when we already have 

Again this is not the issue I raised for addcon.

> 1,$ s/transition/coexistence/g

Nor coexistence.

> well-recognized way to call them. 

Response to this is above.

> which is more or less superceded by ISATAP.

Yes I made an assumption here from 2529 and ISATAP clearly states to not
use multicast.

Best,
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 7 Apr 2007 11:53:05 -0400

Hi Gunter,

Responses in line. 

>    created before the existence of ULA addresses. 

Yes.

>        are sparse within the topology.  

Yes.

>    without global connectivity:

Yes.

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

>    size of the network prefix allocated to the organization.  

Yes.

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

> GV> Does this exist? I assumed that only SLAAC with 64 bit 

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.

>     for stateless autoconfiguration for different then 64 bit 

Yes just want the note.

> as your suggested hard stand):

Could point on point-to-point.

>    considerations one must make when creating and maintain an IPv6 

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

>      be discussed later in this document.

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

> I could do s/an automatic tunneling/an experimental automatic 

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.

> GV> I will let the WG decide on that

OK.

>    addresses as documented in section 4 of RFC3041 [6]

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

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

> >    o  Addresses used by Embedded-RP

ACK.

> GV> I'm not sure I understand the comment? 6to4 puts the IPv4 

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

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

> your suggestions. With ISATAP I will leave it to the WG to 

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

Thanks
/jim

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Apr 2007 09:36:04 -0700

Hi Jim,

Thanks for your comments, and just one thing to follow
 
> use of IPv6 communications without be authorized, etc.

I think there has been for a long time a fundamental
misunderstanding of the ISATAP domain of applicability.
In particular, the ISATAP virtual link connects *router*
interfaces; not host interfaces. As such, packets are not
delivered to/from host interfaces attached to the ISATAP
virtual link; they are forwarded *through* router
interfaces attached to the link.

Therefore, IPv6 packets sent by hosts only traverse
the ISATAP virtual link by being forwarded via a router.
And, since encryption/authentication is required for the
IPv6 packets that are forwarded by a router across the
ISATAP virual link, there is nothing that could happen on
the ISATAP virtual link itself that would compromise IPv6
security.

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Apr 2007 10:28:08 +0200

Fred,

> interfaces attached to the link.

But have all implementations done that? 6to4 was specifically
designed for router-only implementation; the first
widely shipped implementation was for host-based 6to4,
which has well-known issues.

     Brian

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 10 Apr 2007 12:31:59 +0300

> > interfaces attached to the link.

I think I am missing something here. Why does ISATAP have a "model of 
host" and "host variables" if it's meant only for router interfaces?

> which has well-known issues.

I suspect I misunderstood the point. Otherwise, yes, indeed, several 
implementations uses ISATAP as a last hop network, connecting several 
hosts to an (upstream) router over a virtual link.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Apr 2007 07:30:58 -0700

Brian,

> which has well-known issues.

I haven't done a survey of the widely-deployed implementations,
but a host-based ISATAP would be a degenerate case since it
requires that a global IPv6 address with ISATAP interface ID
be assigned on the ISATAP interface and that the ISATAP host
somehow establish trust relationships with ISATAP routers on
the link.

Having the ISATAP nodes act as routers on the ISATAP link
alleviates these issues since only link-locals need be
assigned on the ISATAP interface, and since the trust basis
between routers on the same ISATAP link would be the same as
the trust model for routers attached to any other type of
link in the Internet.

Note that when I say "ISATAP nodes act as routers", I am
specifically not meaning to say that this is restricted
to platforms that we have traditionally thought of as
being routers, since sometimes the end nodes themselves
can be configured as hybrid hosts/routers.

Thanks - Fred

---

From: "Durand, Alain" <[email-masked]>
Date: Tue, 10 Apr 2007 11:12:28 -0400

Fred,

Would that mean that the nodes running ISATAP "as a router"
would have to run a routing protocol?

   - Alain. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Tuesday, April 10, 2007 10:31 AM
> To: Brian E Carpenter
> Cc: Bound, Jim; [email-masked]
> Subject: RE: ISATAP links connect *router* interfaces
> 
> Brian,
> 
> > But have all implementations done that? 6to4 was 
> specifically designed 
> > for router-only implementation; the first widely shipped 
> > implementation was for host-based 6to4, which has well-known issues.
> 
> I haven't done a survey of the widely-deployed 
> implementations, but a host-based ISATAP would be a 
> degenerate case since it requires that a global IPv6 address 
> with ISATAP interface ID be assigned on the ISATAP interface 
> and that the ISATAP host somehow establish trust 
> relationships with ISATAP routers on the link.
> 
> specifically not meaning to say that this is restricted to 
> platforms that we have traditionally thought of as being 
> routers, since sometimes the end nodes themselves can be 
> configured as hybrid hosts/routers.
> 
> Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Apr 2007 08:14:37 -0700

> host" and "host variables" if it's meant only for router interfaces?

The introductory text of (RFC2461, Section 5) says:

   "This section describes a conceptual model of one possible data
   structure organization that hosts (and to some extent routers) will
   maintain in interacting with neighboring nodes."

I interpret this as routers may to some extent behave as
hosts and thus implement certain aspects of the host
specifications. Otherwise, how would ND work for links
that connect only routers (some of which need to be
discovered as "default" by others)? It seem to me it is
up to the individual routers to know which aspects of
the host specifications they need to implement.

> hosts to an (upstream) router over a virtual link.

Maybe what I wrote above helps clarify the distinction
between hosts and routers somewhat. IMHO, this subtle
distinction has been a sticking point in our common
understanding for far too long.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Apr 2007 08:23:53 -0700

Alain,
 
> would have to run a routing protocol?

It is true that routers perform 1) IP forwarding and
2) next-hop determination through participation in a
routing protocol. For 2), when there can be multiple
IP hops in the path to finding a route out of the site,
a traditional routing protocol (either proactive or
reactive) is necessary. But when there can only be a
single IP hop, ND mechanisms are sufficient.

Fred