[db-wg] RE: [ipv6-wg at ripe.net] RPSLng database deployment?

A few additional comments now that the text is cleaned up:

The last sentence of 2.1 is out of context to the heading. The point it is
making really belongs in 2.2. It makes a nice lead-in sentence, and taking
the word 'these' out would probably fix the sentence to make sense as the
start of the next section. 

2.2 ... ', and hence there is no specific security value in the NAT
function.'   That should probably be a stand alone sentence with the 'NAT'
string replaced by 'address translation'. 

The perceived security comes from the lack of pre-established mapping state.
Dynamically establishing state in response to internal requests prevents
unexpected external connections to internal devices.

... the security policy is already likely to consist of multiple components
such as Firewalls, data-filters activity logging and intrusion detection
systems. Simplified forms of these for the less security aware users could
assist to make their private networks more secure.
-delete list-

2.4 ... they do prevent the external tracking and profiling of individual
host computers by means of their IP addresses. 
-(2.3 just talked about how to track if one has access to the NAT, so this
one needs to be explicit about external)-

... which some enterprises believe is a useful ...
- replace 'enterprises' with 'network managers' -

2.5 ... unique and routable IPv4 address will continue increasing as
allocation policies tighten so that they become more difficult to obtain.

'This mechanism allows the simultaneous usage of certain IPv4 prefix for
various end-customers or end-systems.  The overall benefit to the provider
is that fewer globally unique IPv4 addresses are required.'
- This is confusing unless the reader understands the need for stability in
IPv4 end system configurations. RE: how does simultaneous use of an IPv4
address allow the ISP to use fewer addresses? It really doesn't. The ISP
will use as many addresses as it takes for independent instances of an
application. What NAT does in this situation is allow the IPv4 end systems
to have stable addresses that may overlap with other organizations, and the
ISP only needs as many public addresses as there are simultaneous instances
of a given app. -

This type of local control of address resources allow a clean and
hierarchical addressing structure in the network that is not restricted by
the size of the publicly routed address pool. 

2.6.1 ... larger (probably with less-administrative overhead) IPv4 address
range ...

2.6.2 'only have only'  -->> 'have'

'For this type of private networks mainly RFC 1918 addressing is used
internally to reduce the needed amount of global routable prefixes, because
there no need for owned IPv4 prefixes by the enterprise and for simplicity
of the administrative overhead by the lack of a dedicated NOC.'
- I don't buy the argument to begin with. 'Lack of need' is bogus and we
shouldn't propagate it here because it will deflate the value of the IPv6
argument later. We should put this in the context of a cost trade-off,
forfeiting some applications in favor of reduced access costs. How about:
Small networks typically deploy RFC 1918 addressing internally to limit the
explicit charges for publicly routable addresses. This approach also has the
advantage of avoiding the administrative overhead and dedicated NOC
associated with acquiring blocks of publicly routed address space.

2.6.3 ... 'due to the operational stateful operation' ... 
- I think the first operational should go.

2.7 - drop the last sentence. For one those savings are only short term, the
long term costs of dealing with conflicting space will be higher. For two,
the point of the paper is to show how IPv6 makes things better, and even the
simplified renumbering will appear to be more expensive than throwing a NAT
at the problem. If you really want to say something about cost, put it in
the context of -perception-, -short term-, and -simple-.  -

Why is 2.8 different from 2.2?

I though you were going to align the numbering.
2.1 -> 3.2
2.2 -> 3.3
I think we should be able to summarize with a table like:
      Function          2.x    (IPv4)           3.x    (IPv6)
x.1   Simple Gateway    simple management       DHCP-PD
x.2   Simple security   stateful filter         reflexive acl
x.3   tracking          nat state table         global uniqueness
x.4   topology hiding   nat as virtual presence MIPv6
x.5   addressing control RFC 1918               RFC 3177 & ULA
x.6   address allocation RFC 1918               RFC 3177 & ULA
x.7   renumbering        RFC 1918               Multiple addr/interface

Just trying to populate that table might clean up the overlaps and make it
clear what the point of each section should be. If we can delineate the
functions in crisp one or two word labels we can both make it simpler to
understand and more consistent between the versions. As it is even I am
having trouble figuring out if that table is correct. For example 3041 is
listed in 3.5, but it does absolutely nothing for topology hiding. Yes
privacy is one aspect of topology hiding, but end system privacy has nothing
to do with masking the network topology. 

3.2 - why are renumbering & firewalls being discussed in the simple gateway
section? -

3.3 - the first two paragraphs are really summary material about ongoing
evolution in best practices and shouldn't be here. The last paragraph is
somewhat unrelated to the NAT->IPv6 effort. If it stays, comparable text
should be in the IPv4 section that makes it clear that open ports through a
nat will map to multiple machines, so configured state to run servers in the
private space are just as exposed as they would be without the nat. -

3.4 - all of this appears to be too much detail except the next to last
paragraph. The last paragraph is about IPv4 and is already stated there so
it should not be here. -

3.5 - End system privacy and network topology privacy are very separate
topics and shouldn't be in the same section. -

- recommending that people use different subnet structures for internal &
external is just asking for trouble. Most 1st level ops have a hard enough
time with subnets anyway, so making this unnecessarily complex is just a bad
idea. 'Untraceable'/host-routes are a much better plan yet not even
mentioned here. -

3.6 - should be replaced with:
IPv6 provides for autonomy in local use addresses through ULAs (draft-???).
At the same time IPv6 simplifies simultaneous use of multiple addresses per
interface so that a NAT is not required (or even defined) between the ULA
and the public Internet. Nodes that need access to the public Internet
should have a global use address, and may simultaneously have a local use
ULA. Since the IPv6 address space for global use is not a scarce resource
like it is in IPv4, each network should be able to acquire a sufficient
quantity for its needs. While global IPv6 allocation policy is managed
through the Regional Internet Registries, it is expected that they will
continue with derivatives of RFC 3177 for the foreseeable future.

3.7.1 - seems to wander over several topics without a point. -

3.7.3 - if the ISP is allocating /128's then 3041 is not possible.

3.7.x - I still don't see the point in separating these out. There is
nothing that says an ISP can't or shouldn't use DHCP-PD for *every* customer
interface. The point is the length is flexible so any size network fits. If
there is to be a static mapping it should be done on the back side of the
DHCP server. The only time you might get into size distinction here is if
the customer is not part of the ISP aggregate and is therefore injecting
routes. The thing is injecting routes is not a function of IPv4/NAT, so it
really doesn't belong in this document. -

3.9 is really a subset of 3.3

I need to call it a day. I don't have a problem with the current draft going
out as a -00, but we should follow it with a fixed up -01 asap.

Tony 


> -----Original Message-----
> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of
> Bernhard Schmidt
> Sent: Wednesday, October 06, 2004 2:24 PM
> To: db-wg at ripe.net
> Cc: ipv6-wg at ripe.net
> Subject: [ipv6-wg at ripe.net] RPSLng database deployment?
> 
> Dear all,
> 
> having missed the last RIPE meeting I'm unfortunately somewhat out of
> date regarding this, but could someone please enlighten me about the
> current plans for deployment of RPSLng in the regular RIPE database?
> 
> I am using rpslng.ripe.net, but unfortunately almost noone else does.
> Running a network without any sustainable prefix authorization sucks
> quite hard, it is a real pain to have to contact your upstream by mail
> if you have a new prefix (besides other things).
> 
> Are there any problems with RPSLng currently?
> 
> Thanks
> Bernhard