[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Review of draft-ietf-v6ops-nap-02.txt
I am fine with the NAP document most of the below complaints seem to be
personal subjective view by the reviewer and objective technical
statements. The document should ship to RFC. It has been widely
reviewed and presented to the market often and I have not heard any
complaints. Technically I have no issue with any of the sections.
Editing wise I have not scrutinized the document for grammar or spelling
etc. Thus I emphatically disagree strongly with the statements below
from this review.
Best,
/jim
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker
> Sent: Friday, May 26, 2006 12:06 PM
> To: Tony Hain; Brian E Carpenter; EricLKlein;
> gunter@cisco.com; Ralph Droms
> Cc: v6ops@ops.ietf.org; Lindqvist Erik Kurt
> Subject: FW: Review of draft-ietf-v6ops-nap-02.txt
>
> FYI. Margaret's original message seems to have not made it to
> v6ops, or at least through it to me and reportedly several of you.
>
> -----Original Message-----
> From: Margaret Wasserman [mailto:margaret@thingmagic.com] On
> Behalf Of Margaret Wasserman
> Sent: Wednesday, May 24, 2006 7:06 PM
> To: 'iesg@ietf.org'; 'v6ops@ops.ietf.org'
> Subject: Review of draft-ietf-v6ops-nap-02.txt
>
> Hi All,
>
> I reviewed draft-ietf-v6ops-nap-02.txt, and I found a number
> of serious issues with the document. I realize that the Last
> Calls have already completed and that this document is on the
> agenda for this week's IESG telechat, but I consider these
> issues to be serious enough that they are worth raising as
> late objections.
>
> I think that there is a serious problem with the way this
> document describes existing NAT technology. There are
> significant issues with the tone of this document, which is
> arrogant and argumentative. I also believe that the document
> contains several factual mistakes and some potentially
> damaging recommendations. In addition to resolving my review
> comments, I would suggest that the document shepherd request
> a technical review from members of the Transport area who
> focus on NAT-related technologies.
>
> While there are some strong technical points in this
> document, I think that they are severely weakened by the
> length of the document and the level of
> IPv6 marketing hype included in a document that is
> simultaneously bashing NAT providers for exactly this sort of
> behaviour. Little of this hype, including the entire
> appendix, is actually operational advice of any kind, and I
> don't know why the IETF would want to publish it. There are
> already existing groups that market IPv6, and I think that it
> is outside the scope of the IETF to do so.
>
> The authors also seem to have inserted quite a bit of their
> own religion, and I think that there are large parts of this
> document that do not even come close to expressing IETF
> consensus on various topics like NAT features, the usefulness
> of firewalls, appropriate use of the IGP routing practices,
> etc. It seems unlikely that this document has received
> adequate review from people in these areas.
>
> In other words, I think that some of the contents of this
> document and the current editorial style make it unsuitable
> for publication as an RFC.
>
> Specific comments are included below, along with the document
> exerpts that they refer to.
>
> Margaret
>
> ---
>
>
> Abstract
>
> Although there are many perceived benefits to Network Address
> Translation (NAT), its primary benefit of "amplifying" available
> address space is not needed in IPv6. In addition to NAT's many
> serious disadvantages, there is a perception that other benefits
> exist, such as a variety of management and security
> attributes that
> could be useful for an Internet Protocol site. IPv6 does
> not support
> NAT by design and this document shows how Network Architecture
> Protection (NAP) using IPv6 can provide the same or more benefits
> without the need for NAT.
>
> This abstract seems very slanted. I also think that it would
> be incorrect at this point to say that "amplifying" address
> space is the primary benefit of NATs, as many companies use
> them in spite of the fact that they have plenty of address
> space available.
>
> There are at least three other _real_ benefits of NAT boxes.
> While I hold with this document's position that these
> benefits can and should be realized in other ways in IPv6, I
> do not think it is factual or helpful to argue that they
> don't exist. Those benefits are:
>
> (1) Avoiding the reliance of internal network number on
> externally allocated numbers. AKA not having to renumber
> when you change ISPs or when ISPs change address allocation
> strategies.
>
> (2) Hiding internal topology from external communicants.
>
> (3) Avoiding the establishment of unauthorized inbound connections.
> While this NAT side effect can also cause problems, it does
> provide the real benefits of a stateful firewall.
>
> 1. Introduction
>
> Although there are many perceived benefits to Network Address
> Translation (NAT), its primary benefit of "amplifying" available
> address space is not needed in IPv6. The serious disadvantages of
> ambiguous "private" address space and of Network Address
> Translation
> (NAT) [1][5] have been well documented [4][6]. However, given its
> wide market acceptance NAT undoubtedly has some perceived
> benefits.
> Indeed, in an Internet model based on universal any-to-any
> connectivity, product marketing departments have driven a
> perception
> hat some connectivity and security concerns can only be solved by
> using a NAT device or by using logically separated Local
> Area Network
> (LAN) address spaces. This document describes the reasons for
> utilizing a NAT device in an IPv4 environment that are regularly
> cited in marketing pronouncements. It then shows how
> these needs can
> be met without using NAT in an IPv6 network. Some of the IPv6
> solutions offer advantages beyond the equivalent IPv4 NAT
> solution.
> The use of the facilities from IPv6 described in this
> document avoids
> the negative impacts of address translation.
>
>
> I don't understand, at all, the mentione of "marketing departments"
> and "marketing pronouncements" in this section and think it
> should be reworded to remove them and/or cite specific
> documents. There are real reasons why people use NATs in
> IPv4, and there are better ways to do those things with IPv6.
> That's what we should say. The text in the above paragraph
> is insulting, incorrect and very likely to get the network
> administrator to stop reading before you can offer any advice
> on how to set-up an IPv6 network.
>
>
> 2. Perceived Benefits of NAT and its Impact on IPv4
>
> This section provides insight into the generally
> perceived benefits
> of the use of IPv4 NAT as extolled by product marketing.
> The goal of
>
>
> Again with the "product marketing". Do the authors of this
> document really believe that these benefits do not exist?
> Does the IETF as a whole? I think we should be somewhat
> embarrassed to publish this document as-is, because it seems
> very naive and one-sided. This continues throughout the
> document, but I will not continue to mention it.
>
> 2.2. Simple Security due to Stateful Filter Implementation
>
> A firewall doesn't fully secure a network, because many
> attacks come
> from inside or are at a layer higher than the firewall can protect
> against. In the final analysis, every system has to be
> responsible
> for its own security, and every process running on a
> system has to be
> robust in the face of challenges like stack overflows etc. What a
> firewall does is prevent a network administration from
> having to pay
> for bandwidth to carry unauthorized traffic, and in so
> doing reduce
> the probability of certain kinds of attacks across the protected
> boundary.
>
> This is the section where we are describing the benefits of
> NAT without analyzing them. So, why is this sub-section
> here? It is clear that the side effects of NAT can be used
> as one element of a system to protect internal nodes. It is
> not sufficient to protect them from everything, which doesn't
> mean that it doesn't protect them against anything. Much of
> this section could appear to be an argument that firewalls of
> all kinds are useless because of the existence of Trojan
> Horse-style attacks, which is obviously false. Have any
> firewall experts been asked to review this section? If not,
> I think you should ask someone like Steve Bellovin to do so.
>
>
> 2.3. User/Application tracking
>
> Although NATs create temporary state for active sessions,
> in general
> they provide limited capabilities for the administrator
> of the NAT to
> gather information about who in the private network is requesting
> access to which Internet location. This could in theory
> be done by
> logging the network address translation details of the private and
> the public addresses from the NAT device's state database.
>
> The checking of this database is not always a simple
> task, especially
> if Port Address Translation is used. It also has an unstated
> assumption that the administrative instance has a mapping
> between an
> IPv4-address and a network element or user at all times, or the
> administrator has a time-correlated list of the address/port
> mappings.
>
>
> I think that this document is arguing that User/Application
> tracking is not a benefit of NAT? If so, why is it even in
> this document?
>
> 2.4. Privacy and Topology Hiding
>
> The goal of 'topology hiding' is to provide devices on the private
> network with an identifier (IPv4 address) which an entity
> outside the
> network can use to communicate with or to reference the private
> network devices in protocols but prevents the external
> entity making
> a correlation between the topological location of the
> private device
> and the address on the local network.
>
> The above sentence does not parse (editorial).
>
> The use of NAT then results in a user behind a NAT
> gateway actually
> appearing on the Internet as a user inside the NAT box
> itself; i.e.,
> the IPv4 address that appears on the Internet is only
> sufficient to
> identify the NAT. When concealed behind a NAT it is impossible to
> tell from the outside which member of a family, which
> customer of an
> Internet cafe, or which employee of a company generated
> or received a
> particular packet. Thus, although NATs do nothing to provide
> application level privacy, they do prevent the external
> tracking and
> profiling of individual host computers by means of their IP
> addresses, usually known as 'device profiling'. At the
> same time a
> NAT creates a smaller pool of addresses for a much more
> focused point
> of attack.
>
> What does the last sentence mean? Give some sort of example
> or take it out, perhaps?
>
> 3.4. Untraceable IPv6 Addresses
>
> These should be globally routable IPv6 addresses which can be
> randomly and independently assigned to IPv6 devices.
>
> The random assignment is intended to mislead the outside
> world about
> the structure of the local network. However the local
> network needs
> to maintain a correlation between the location of the
> device and the
> untraceable IPv6 address. This correlation could be done by
> generating IPv6 host route entries or by utilizing an indirection
> device such as a Mobile IPv6 Home Agent.
>
> Is not technically sound to advocate the dissemination of
> host routes in the IGP for infrastructure hiding. IGPs are
> not designed to scale well for this sort of use. It would be
> much more technically sound to advocate the use of
> L2 switching to avoid exposure of network topology at L3.
>
> Besides, I thought the point of network address hiding (or
> one of them), as outlined above was to avoid the ability to
> identify different nodes by address for port scanning
> purposes, not (merely) to avoid the ability to tell what
> subnets they are on. The proposed technique doesn't seem to
> address that issue at all.
>
> With external connectivity the simple gateway could also
> use DHCP-PD
> to acquire a routing prefix from the service provider for use when
> connecting to the global Internet. End-system
> connections involving
> other nodes on the global Internet will always use the global IPv6
> addresses [9] derived from this prefix delegation. It should be
> noted that the address selection policy table in
> end-systems needs to
> be correctly set up so that true global prefixes are distinguished
> from ULAs and will be used for the source address in
> preference when
> the destination is not a ULA.
>
> Unless one takes steps to actively screw this up, a globally
> routable destination address will always have a
> longest-prefix match with a globally routable source and a
> ULA will always have a longest-prefix match with a ULA. So,
> the last sentence is completely unnecessary and somewhat misleading.
>
> The tricky part is making sure that the node uses the right
> _destination_ address -- a ULA for local traffic and global
> address for non-local traffic.
> This will generally require the use of some type of split
> DNS, with ULAs returned internally but not externally.
>
> In the very simple case there is no explicit routing
> protocol and a
> single default route is used out to the global Internet.
> A slightly
> more complex case might involve local routing protocols,
> but with the
> entire local network sharing a common global prefix there
> would still
> not be a need for an external routing protocol as a default route
> would continue to be consistent with the connectivity.
>
> I don't understand this paragraph at all. What does it have
> to do with ULAs? Also, the second half of this sentence
> doesn't make sense.
> I'm not 100% sure what it means, but if it means what I think
> it means, it is wrong.
>
> 4.2. IPv6 and Simple Security
>
> The vulnerability of an IPv6 host is similar to that of
> an IPv4 host
> directly connected towards the Internet. The use of firewall and
> Intrusion Detection Systems (IDS) is recommended. A proxy may be
> used for certain applications, but with the caveat that the end to
> end transparancy is broken. However, with IPv6, the following
> protections are available without the use of NAT while maintaining
> end-to-end reachability:
> 1. Short lifetimes on privacy extension suffixes reduce
> the attack
> profile since the node will not respond to the
> address once the
> address is no longer valid.
> 2. IPsec is a mandatory service for IPv6 implementations. IPsec
> functions to prevent session hijacking, prevent content
> tampering, and optionally masks the packet contents.
> While IPsec
> might be available in IPv4 implementations, deployment in NAT
> environments either breaks the protocol or requires complex
> helper services with limited functionality or efficiency.
>
> IPsec performs exactly the same purposes in IPv4 as IPv6. I
> don't know of any stacks that implement IPsec for IPv6 and
> not for IPv4.
> Also, it is not clear that end-to-end IPsec is fundamentally
> useful, even without the interference of a NAT box, as I
> believe that there needs to be some sort of binding to the
> upper layer protocol in order for IPsec to provide these protections.
>
> If you decide to keep this section, you should acknowledge
> that use of the
> IPv6 stateful firewall mechanisms advocated in bullet 3 will
> present similar obstacles to using IPsec.
>
>
> 3. The size of the address space of a typical subnet (64 bits of
> IID) will make an effective network ping sweep and resulting
> port-scan virtually impossible due to the number of possible
> combinations available, provided that IIDs are essentially
> randomly distributed across the available space.
>
> IIDs will not be randomly distributed. They are based on
> EUI-64 IDs which are certainly not randomly distributed. In
> fact, on Ethernet 16 of the 64-bits will have a known value.
> Also, the numbering space for the first three bytes (24-bits)
> is not completely allocated and there is very clearly an
> unbalanced distribution in that space. The fact that
> companies tend to buy somewhat homogenous hardware can make
> it possible to guess which three-byte combinations are most
> likely to be present within a given company. So, the length
> of the IID offers nowhere near the level of protection
> described above.
>
>
> This protection is nullified if the attacker has no
> access to a
> local connection. If an attacker has local access then he
> could use ND [3] and ping6 to ff02::1 to detect local
> neighbors. (Of course, a locally connected attacker has many
> scanning options with IPv4 as well.) It is recommended for
> site administrators to take [18] into consideration to achieve
> the expected goal. This protection will also be nullified if
> IIDs are configured in a group near the start of the
> IID space.
>
> Assuming the network administrator is aware of [18] the increased
> size of the IPv6 address will make topology probing much
> harder, and
> almost impossible for IPv6 devices. The intention of topology
> probing is to identify a selection of the available hosts
> inside an
> enterprise. This mostly starts with a ping-sweep. Since the IPv6
> subnets are 64 bits worth of address space, this means that an
> attacker has to send out a simply unrealistic number of
> pings to map
> the network, and virus/worm propagation will be thwarted in the
> process. At full rate 40Gbps (400 times the typical
> 100Mbps LAN, and
> 13,000 times the typical DSL/Cable access link) it takes over 5000
> years to scan a single 64 bit space.
>
> See my comments above about why this is not correct.
>
> 4.3. User/Application Tracking
>
> IPv6 enables the collection of information about data
> flows. Due to
> the fact that all addresses used for Internet and
> intra-/inter-site
> communication are unique, it is possible for an
> enterprise or ISP to
> get very detailed information on any communication
> exchange between
> two or more devices. This enhances the capability of data-flow
> tracking for security audits compared with IPv4 NAT,
> because in IPv6
> a flow between a sender and receiver will always be uniquely
> identified due to the unique IPv6 source and destination
> addresses.
>
> Why is this mentioned in this document? Given this
> paragraph, I think you have perversely stated another benefit
> of NAT -- that my ISP cannot effectively track this
> information on a per-machine basis.
> Also, how is this consistent with the idea that IPv6 will use
> privacy address for client communications?
>
> There are two possible scenarios for the extreme situation when a
> network manager also wishes to fully conceal the internal IPv6
> topology.
>
> o One could use explicit host routes and remove the correlation
> between location and IPv6 address. This solution does however
> show severe scalability issues.
>
> Right. That is why we should not recommend it.
>
> o The other technology to fully hide the internal
> topology would be
> to use a tunneling mechanism. Mobile IPv6 without route
> optimization is one example. In this example the public facing
> addresses are indirected via an edge Home Agent (HA). This
> indirection method truly masks the internal topology
> as all nodes
> with global access appear to share a common prefix.
> The downside
> of using this method is that it makes usage of
> middleware like a
> Home Agent (HA).
>
> This seems awfully complex and may present other problems,
> such as brittleness and MTU/fragmentation issues.
>
> What are the possible benefits of subnet hiding that could
> justify this type of solution?
>
> There are other answers involving L2 bridging with VLANs for
> limiting broadcast domains that are much more scalable and
> simpler than either of these approaches.
>
>
> 4.5. Independent Control of Addressing in a Private Network
>
> [...]
>
> When using IPv6, the need to ask for more address space
> will become
> far less likely due to the increased size of the subnets. These
> subnets typically allow 2^64 addresses per subnet and an
> enterprise
> will typically receive a /48 which allows segmentation
> into at least
> 2^16 different subnets.
>
> The ongoing subnet size maintenance may become simpler when IPv6
> technology is utilised. If IPv4 address space is
> optimised one has
> to look periodically into the number of hosts on a segment and the
> subnet size allocated to the segment; an enterprise today
> may have a
> mix of /28 - /23 size subnets for example, and may
> shrink/grow these
> as their network user base changes. For IPv6 all subnets have /64
> prefixes.
>
> I am not really sure what any of this has to do with
> anything, and it isn't entirely correct. The 64-bit IID is a
> hard limit in IPv6, but there is no hard limit that all sites
> will be allocated a /48.
>
> 4.6. Global Address Pool Conservation
>
> IPv6 provides sufficient space to completely avoid the need for
> overlapping address space,
> 340,282,366,920,938,463,463,374,607,431,768,211,456
> (3.4*10^38) total
> possible addresses. As previously discussed, the serious
>
> The naivete of pointing out the number of possible IPv6
> addresses actually hurts this argument. Because of the
> 64-bit IID and the IETF's recommendations to allocate a /48
> to home users, the address space will be much less densely
> used than in IPv4. Many people still feel that there will be
> enough address space that conservation is not needed, and
> there are decent documents that you could cite that make that
> argument. This has little or nothing to do with the number
> of possible addresses in IPv6, though.
>
> disadvantages of ambiguous address space have been well
> documented,
> and with sufficient space there is no need to continue the
> increasingly aggressive conservation practices that are necessary
> with IPv4. While IPv6 allocation policies and ISP
> business practice
> will continue to evolve, the recommendations in RFC 3177
> are based on
> the technical potential of the vast IPv6 address space. That
> document demonstrates that there is no resource
> limitation which will
> require the adoption of the IPv4 workaround of ambiguous
> space behind
> a NAT. As an example of the direct contrast, many
> expansion oriented
> IPv6 deployment scenarios result in multiple IPv6 addresses per
> device, as opposed to the constriction of IPv4 scenarios where
> multiple devices are forced to share a scarce global address.
>
> 4.7. Multihoming and Renumbering
>
> Multihoming and renumbering remain technically
> challenging with IPv6
> (see the Gap Analysis below). However, IPv6 was designed to allow
> sites and hosts to run with several simultaneous
> CIDR-like prefixes
> and thus with several simultaneous ISPs. An address selection
> mechanism [10] is specified so that hosts will behave consistently
> when several addresses are simultaneously valid. The fundamental
> difficulty that IPv4 has in this regard therefore does
> not apply to
> IPv6. IPv6 sites can and do run today with multiple ISPs
> active, and
> the processes for adding and removing active prefixes at
> a site have
> been documented [12] and [19].
>
> To be balanced, you should at least say something here about
> the fact that end-user sites that currently have "swamp
> space" addresses in IPv4 may need to move ot ISP-provided
> addresses in IPv6, thus increasing concerns about renumbering
> and multi-homing.
>
> If there is need to mask the internal structure towards
> the external
> IPv6 internet, then some form of 'untraceable' addresses
> may be used.
> These addresses will be derived from a local pool, and may be
> assigned to those hosts for which topology masking is required or
> which want to reach the IPv6 Internet or other external networks.
> The technology to assign these addresses to the hosts
> could be based
> on DHCPv6. To complement the 'Untraceable' addresses it
> is needed to
> have at least awareness of the IPv6 address location when
> routing an
> IPv6 packet through the internal network. This could be
> achieved by
> 'route-injection' in the network infrastructure. This route-
> injection could be done based on /128 host-routes to each
> device that
> wants to connect to the Internet using an untraceable
> address. This
> will provide the most dynamic masking, but will have a scalability
> limitation, as an IGP is typically not designed to carry many
> thousands of IPv6 prefixes. A large enterprise may have
> thousands of
> hosts willing to connect to the Internet. Less flexible masking
> could be to have time-based IPv6 prefixes per link or
> subnet. This
> may reduce the amount of route entries in the IGP by a significant
> factor, but has as trade-off that masking is time and
> subnet based.
>
> This whole "untraceable" address concept seems to be poorly
> thought- out. I am concerned that this document, while
> supposedly an informational document on existing IPv6
> features is trying to specify a new IPv6 feature and doing it
> quite inadequately, IMO.
>
> While a full prefix is expected to be the primary deployment model
> there may be cases where the ISP provides a single IPv6
> address for
> use on a single piece of equipment (PC, PDA, etc.).
>
> How does this differ from the "single user connection" case
> described in 5.3?
>
> 6.1. Subnet Topology Masking
>
> There really is no functional gap here as a centrally
> assigned pool
> of addresses in combination with host routes in the IGP is an
> effective way to mask topology.
>
> You discuss the scaling issues in your own document, so this
> seems to be misleading.
>
> 6.4. Site Multihoming
>
> This complex problem has never been completely solved for
> IPv4, which
> is exactly why NAT has been used as a partial solution. For IPv6,
> after several years' work, the IETF has converged on an
> architectural
> approach intended with service restoration as initial aim [20].
> Again, ULAs may help since they will provide stable addressing for
> internal communications that are not affected by multihoming.
>
>
> Depending on what benefits are expected from multihoming, the
> capacity for
> IPv6 to use more than one prefix per interface may help here, too.
>
> Appendix A. Additional Benefits due to Native IPv6 and
> Universal Unique
> Addressing
>
> I am not really sure that including a "marketing brochure"
> regarding the general benefits of IPv6 at the end of this
> document serves to make it any clearer.
>
> The users of native IPv6 technology and global unique
> IPv6 addresses
> have the potential to make use of the enhanced IPv6
> capabilities, in
> addition to the benefits offered by the IPv4 technology.
>
> A.1. Universal Any-to-Any Aonnectivity
>
> Connectivity, perhaps?
>
> A.4. Increased Security Protection
>
> The security protection offered by native IPv6 technology is more
> advanced than IPv4 technology. There are various transport
> mechanisms enhanced to allow a network to operate more
> securely with
> less performance impact:
> o IPv6 has the IPsec technology directly embedded into the IPv6
> protocol.
>
> See note above. IPsec is no more "embedded" in IPv6 than it
> is in IPv4.
>
> This allows for simpler peer-to-peer encryption and
> authentication, once a simple key/trust management model is
> developed, while the usage of some other less secure
> mechanisms is
> avoided (i.e. md5 password hash for neighbor authentication).
> o On a local network, any user will have more security awareness.
>
> IPv6 will make users more security-aware? What does that even mean?
>
> This awareness will motivate the usage of simple firewall
> applications/devices to be inserted on the border between the
> external network and the local (or home network) as there is no
> Address Translater and hance no false safety perception.
> o All flows on the Internet will be better traceable due
> to a unique
> and globally routable source and destination IPv6
> address. This
> may facilitate an easier methodology for back-tracing
> DoS attacks
> and avoid illegal access to network resources by
> simpler traffic
> filtering.
>
> We already can trace these flows inside the NAT just fine.
> The only place it is now easier to trace is outside my NAT,
> where the attackers live.
>
> o The usage of private address-space in IPv6 is now provided by
> Unique Local Addresses, which will avoid conflict
> situations when
> merging networks and securing the internal communication on a
> local network infrastructure due to simpler traffic filtering
> policy.
>
> How is this a security benefit?
>
> 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.
>
> Again, how is this a security benefit?
>
> A.5. Mobility
>
> Anytime, anywhere, universal access requires MIPv6 services in
> support of mobile nodes. While a Home Agent is required
> for initial
> connection establishment in either protocol version, IPv6 mobile
> nodes are able to optimize the path between them using the MIPv6
> option header while IPv4 mobile nodes are required to
> triangle route
> all packets. In general terms this will minimize the network
> resources used and maximize the quality of the communication.
>
> Nice plug for MIP6, but why is it here? And, have you run
> this text by the
> MIP4 WG to make sure that they agree with it?
>
> A.7. Community of interest
>
> Although some Internet-enabled devices will function as
> fully- fledged
> Internet hosts, it is believed that many will be operated
> in a highly
> restricted manner functioning largely or entirely within
> a Community
> of Interest. By Community of Interest we mean a
> collection of hosts
> that are logically part of a group reflecting their ownership or
> function. Typically, members of a Community of Interest need to
> communicate within the community but should not be generally
> accessible on the Internet. They want the benefits of the
> connectivity provided by the Internet, but do not want to
> be exposed
> to the rest of the world. This functionality will be available
> through the usage of NAP and native IPv6 dataflows, without any
> stateful device in the middle. It will also allow to
> build virtual
> organization networks on the fly, which is very difficult to do in
> IPv4+NAT scenarios.
>
> Uh... What is this all about? VPNs? Something else? Why
> is this different in IPv6 than in IPv4?
>
>