Hi,
(co-chair hat on)
(hat off)
Long mails take a while to digest.. sorry. Inline... (I've snipped the text we seem to be in pretty clear agreement about.)
At 14:31 8/11/2004 +0200, Pekka Savola wrote:On Thu, 14 Oct 2004, Brian E Carpenter wrote:The authors would be interested in comments on the draft below.
Thanks. Mine below. I think this is an important and very well-written draft.
I recognize a number of recommendations/v6 approaches which I definitely don't like, but would rather see changed (if it was possible), but because this draft is meant more as a political document I understand why those (more or less) have to be in there...
substantial -----------
2. Perceived benefits of NAT and its impact on IPv4
This section provides visibility into the generally perceived benefits of the use of IPv4 NAT. The goal of this description is not to analyze these benefits or discus the rightfulness of the perception, but to identify the connectivity and security prerequisites to deploy IPv6 to functionally replace IPv4 combined with a NAT device.
==> as said above, this is a practically good approach at finishing this document in finite time. I just hope it would have been possible to insert some enlightenment, possibly a subsection per existing subsection, saying why a particular concern is not such a big problem or is a bad idea. You never know, someone could even be convinced about it.... :-)
Maybe we should do that in appendix or so. We have tried to provide some ventilation or 2th thoughts on a certain perceived benefit, but we also would like to avoid writing new rfc 2993.
OK.
This simple rule would create similar protection and security holes the typical IPv4 NAT device will offer and may for example be enabled by default on all broadband edge-routers. but with that difference that the security caveats will be documented, and may hence be removed with the next revision of the rule.
==> this also needs to discuss how to not throw away the baby with the bathwater, i.e., how one could deploy e.g. new apps (like p2p) without having to do the same kind of firewall traversal as v4. This probably would need some signalling mechanism or something.. Probably an issue to be investigated.
This sounds like the work that Jordi wants to achieve with his distributed security draft? I've added note that we need to discus this little broader in the context of NAP.
Well, there are two approaches here:
Based on the amount of connections and required network services the network design and addressing dynamics are different.
==> what "connections"? _simultaneous_? TCP connections or flows in general?
This refers to physical connections. I can't see how to identify a physical
link any better in a simple way. maybe the terminology 'physical interconnection' can
be used
Ack.
IPv6 allows also for innovative usage of the IPv6 address length, and makes it possible to embed the multicast 'Rendez-Vous Point' (or RP) directly in the IPv6 multicast address when using ASM multicast. this is not possible with limited size of the IPv4 address.
==> I guess it might also be worth saying that using this approach simplifies the multicast model considerably, making it easier to understand and to deploy.
I proposed following text based on your comment:
<snip>
<t>IPv6 allows also for innovative usage of the IPv6 address length, and makes
it possible to embed the multicast 'Rendez-Vous Point' (or RP) directly in the
IPv6 multicast address when using ASM multicast. this is not possible with
limited size of the IPv4 address. This approach also simplifies the multicast
model considerably, making it easier to understand and deploy </t>
<end snip>
OK.
o The technology to enable source-routing on a network infrastructure has been enhanced to allow this feature to function, without impacting the processing power of intermediate network devices. The only devices impacted with the source-routing will be the source and destination node and the intermediate source-routed nodes. This impact behavior is different if IPv4 is used, because then all intermediate devices would have had to look into the source-route header. Looking into the source-route header consumed CPU power of these devices and was generally discouraged to be enabled on a network due to potential Denial-of-Service attack potential.
==> this is technically not correct. Both v4 and v6 behave the same way; the routing header is only processed by those nodes who are at the destination address (before it's changed), so on-path nodes don't need to peek at the packets. I suggest this bullet be removed.
Will look deeper into it. I always believed that a router falls back to CPU switching from the moment an option is set in the IPv4 header as the router doesn't know which options were used. This is one of the (many) reasons ISP don't allow this through the network as it eats-up CPU cycles and makes forwarding these packets slow.
but as you seem so certain i will double-check.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings