Skip to main content

Local Network Protection for IPv6
RFC 4864


Lars Eggert
(David Kessens)

No Objection

(Cullen Jennings)
(Dan Romascanu)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Russ Housley)


(Ted Hardie)


(Brian Carpenter)

Note: This ballot was opened for revision 06 and is now closed.

Lars Eggert
David Kessens Former IESG member
Yes () Unknown

Bill Fenner Former IESG member
(was Discuss) No Objection
No Objection (2006-10-02) Unknown
3.4 and 6.2 still just say "small" but since 4.4 has enough specifics, I'll clear my DISCUSS.
Cullen Jennings Former IESG member
(was No Record, Discuss) No Objection
No Objection (2006-10-28) Unknown

Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (2006-11-14) Unknown
I am generally happy with the new version.
Margaret Wasserman sent the following comments.
It would be great if you could address at least
her substantive comments, all of which is easy
as far as I can see.


>1.  Introduction
>   There have been periodic claims that IPv6 will require a Network
>   Address Translation (NAT), because with IPv4 people use NAT to
>   accomplish that person's preferred task.

[Editorial] What person?  Perhaps change to:

   There have been periodic claims that IPv6 will require Network
   Address Translation (NAT), because IPv4 network administrators
   use NAT to meet a variety of needs that will also need to be
   met when using IPv6.

>   This document will explain
>   why those pronouncements are false by showing how to accomplish the
>   task goal without address translation.

[Editorial] s/pronouncements/claims
[Editorial] s/the task goal/those goals

[Editoral] Start new paragraph.

>   Although there are many
>   perceived benefits to NAT, its primary benefit of "amplifying"
>   available address space is not needed in IPv6.  The serious

>   This document describes the goals for utilizing a NAT device in an
>   IPv4 environment that are regularly cited as solutions for perceived
>   problems.

[Editorial] Goals cannot be cited as solutions for perceived problems,
can they?  How about:

     This document describes the goals that are commonly met in IPv4
     networks through the use of NAT.

>   It then shows how these needs can be met without using the

[Editorial] s/needs/goals

>   Another consideration discussed is the view that NAT can be used to
>   fulfill the goals of a security policy.  At a technical level the
>   translation process fundamentally can not produce security because
>   mangling the address in the header does not fulfill any useful
>   security functions;

[Substantive] Later on, you talk about the value of all nodes
appearing to be at the edge of the network, hiding the internal
topology from attackers and you propose a solution to provide the
same type of protection in IPv6.  That is inconsistent with this
paragraph, so I'd suggest that you remove this paragraph.

>   in fact it breaks the ability to produce an audit
>   trail which is a fundamental security tool.  That said, the artifacts
>   of NAT devices do provide some value.
>   1.  The need to establish state before anything gets through from
>       outside to inside solves one set of problems.
>   2.  The need to stop receiving any packets when finished with a flow
>       solves a set of problems
>   3.  the need to appear to be attached at the edge of the network
>       solves a set of problems
>   4.  and the ability to have addresses that are not publicly routed
>       solves yet another set (mostly changes where the state is and
>       scale requirements for the first one).

[Editorial/maybe Substantive] The content of this list is very confusing.
According to the previous paragraph, this would seem to be a list of the
ways in which NATs provide value.

The first bullet is okay, as NAT requires that users establish state
before anything comes in from the outside, and the last bullet is
also okay, as NATs provide the ability to use non-publicly routed
addresses.  But the other bullets make less sense.  NATs do not impose
"the need to stop receiving packets" or "the need to appear attached to
the edge of the network".

You could instead say something like

     2. NAT state expirations stops allowing inbound connections
         after an application completes, which solves a set of problems.
     3. Making all nodes appear as though they are attached at
         the edge of the network solves a set of problems.

>          Goal                 IPv4                    IPv6
>   +------------------+-----------------------+-----------------------+
>   | Simple Gateway   |  DHCP - single        |  DHCP-PD - arbitrary  |
>   | as default router|  address upstream     |  length customer      |
>   | and address pool |  DHCP - limited       |  prefix upstream      |
>   | manager          |  number of individual |  SLAAC via RA         |
>   |                  |  devices downstream   |  downstream           |
>   |                  |  see section 2.1      |  see section 4.1      |
>   +------------------|-----------------------|-----------------------+

[Editorial] Define SLAAC before use.

>   o  One approach uses explicit host routes in the IGP to remove the
>      external correlation between physical topology attachment point
>      and end-to-end IPv6 address.  In the figure below the hosts would
>      be allocated prefixes from one or more logical subnets, and would
>      inject host routes to internally identify their real attachment
>      point.  This solution does however show severe scalability issues
>      and requires hosts to securely participate in the IGP, as well as
>      having the firewall block all external to internal traceroute for
>      the logical subnet.  The specific limitations are dependent on the
>      IGP protocol, the physical topology, and the stability of the
>      system.  In any case the approach should be limited to uses with
>      substantially fewer than the maximum number of routes that the IGP
>      can support (generally between 5,000 and 50,000 total entries
>      including subnet routes).  Hosts should also listen to the IGP for
>      duplicate use before finalizing an interface address assignment as
>      the duplicate address detection will only check for use on the
>      attached segment, not the logical subnet.

[Substantive]  This is a _much_ improved description of this mechanism.
However, I am still of the opinion that an informational document is not
the right place to define a new untraceable addressing mechanim.

[Editorial] Including the picture after all three bullets makes it unclear
which mechanism is pictured.  Maybe re-order to put this one last, or
add a sentence to make it clearer which is pictured?

>   o  On a local network, any user will have more security awareness.
>      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 Translator and hence no false safety perception.

[Substantive] IPv6 will not make users have more security awareness.
When we say something like this, we are emitting the same type of
marketing hype that we deride in the vendors of NAT products.  This
bullet should just be omitted.

[Editorial] Although all but one of the specific problems I had with the
text in Appendix A have been fixed, I am still not sure why an
appendix on the benefits of IPv6 belongs in this document.
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

Mark Townsley Former IESG member
No Objection
No Objection () Unknown

Russ Housley Former IESG member
No Objection
No Objection () Unknown

Ted Hardie Former IESG member
Abstain () Unknown

Brian Carpenter Former IESG member
Recuse () Unknown