Jeroen,
> -----Original Message-----
> From: Jeroen Massar [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 25, 2007 9:00 AM
> To: Templin, Fred L
> Cc: bill fumerola; [email protected]
> Subject: Re: draft-ietf-ipv6-ula-central-02.txt
>
> Templin, Fred L wrote:
> [..]
> >> If you are only connecting to another ULA network, then
> why would one
> >> ever need NS entries in ip6.arpa for this space?
> >
> > To aid in connecting to another ULA network.
>
> So you are able to setup routing between those two sites, but feeding
> them with NS entries for your reverse is too hard? IMHO the latter is
> actually much easier, just find the DNS servers for the site, presto.
I didn't quite understand this, but I am not a DNS expert.
> >> The whole story is about having NS entries in the ip6.arpa
> >> tree for the
> >> delegation. When you have a delegation in the Internet
> ip6.arpa tree,
> >> you also need to query them one way or the other and thus you are
> >> connecting your ULA-based network to that Internet.
> >
> > Connecting to the IPv4 Internet in order to query the
> > ip6.arpa tree should work fine; right?
>
> Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't
> matter, you have a dependency on the Internet. As such you are not
> working dis-connected from the Internet and you have a
> dependency on it.
Only when you want to connect to another site.
> I was under the impression, clearly wrongly, that people wanted ULA so
> they where completely independent of the Internet with no ties there
> whatsoever.
I can't speak for the use cases other people might have
in mind.
> >> Also, people will the notice that they can use reverses from the
> >> Internet, at one point or another will also want to use
> SIP or various
> >> other protocols and thus end up using the Internet, and
> there are two
> >> ways to do that: NAT it or simply announce the ULA prefix,
> renumbering
> >> to a PI block is of course not an option here.
> >
> > I don't see how that follows, and I do not want IPv6 NAT.
>
> There are a lot of networks that only where "local" and used RFC1918
> because of this, then at a certain point "oeh we merge", and
> they had to
> connect to another network (which then clashed and also caused NAT and
> other weird things but that is another point). That 'other' network
> sometimes was the Internet, as "oeh it is handy that we can access
> google/wikipedia/etc" and instead of renumbering, lets NAT, as that is
> easy quick and 'cheap', they forget though how much pain it is in the
> long run.
Again, *no* NAT'ing of IPv6.
> >> As such, what is the 'local' part again, how local is it really?
> >> And how is ULA-C then different from PI? Why bother people with
> >> this ULA-C thing when they really need PI in the first place?
> >> Which they can already get for $100/year from ARIN and which will
> >> be guaranteed unique, just like all other address space
> from the RIR's.
> >
> > IMHO, a "site" can be as large as a major corporation's private
> > Intranet or as small as my laptop, and I don't want to have to
> > pay $100/yr just to connect my laptop to other sites.
>
> A site is a network of computers with a single
> administration,
A laptop fits this description. Think of one running some
of this new virtualization support whereby there may be
many virtual machines connected up by virtual networks
running within the laptop. (Actually, folks like IBM were
doing this "new" virtualization on their mainframes back
in the 70's...)
> this can
> mean indeed a major corporation (who maybe even require multiple /48's
> which is why rfc4193 is a bit off to cover those cases)
>
> If you want to have a /48 for your laptop, simply use ULA (RFC4193)
> those are free.
RFC4193 ULA is good, but could be better. However remote the
possibility of collisions, IMHO there would still be value in
having a 3rd-party mechanism to avoid duplicate assignments
and/or de-conflict duplicates.
> Or are you simply wanting to have your own IP
> addresses,
> setting up firewalling etc because you have a laptop (or Winnebago
> filled with servers) and carrying it around globally through various
> buildings and making other networks accept your /48 AND force them to
> connect to the Internet to be able to resolve your reverse?
I don't quite understand this, but I want to be able to
drop my laptop down in whatever visited network and have
it connect to other sites w/o having to manually configure
explicit VPNs.
> Most likely anyway when you connect your laptop to another site they
> will be providing you with an IP address anyway from their
> site prefix.
One use I could see for that is if you needed a care-of
address such as used for MIPv6. But, that gets off onto
a completely different line of discussion.
> Can you clarify the use case you are sketching here a lot more as I
> really want to know what actual use case is actually useful that ULA-C
> solves, what PI doesn't solve (Drawings + text help). Especially now
> that the folks who 'want/need' ULA-C do want to have reverse DNS
> available from the Internet, while they want to be local in
> the first place.
I already gave my use-case in:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html
a drawing is also attached (see below).
> All those cases can be covered perfectly fine by PI. Or is it
> just that
> folks see ULA-C as 'very cheap PI space'?
Again, I don't know about other folks but for me I see the
price as too high for some "sites" to have to pay.
Fred
[EMAIL PROTECTED]
Egress Interfaces
^ ^ ^
| | |
+------------------------+---+--------+----------+
| | | | | M
| ,-. | | | .... | | A
| (H1 )---+ +---+---+--------+---+ | N
| `-' | | | | E
| | +-----+ +------+--< T
| . | +---+ | | | |
| . +--|R1 |---+ | | | I
| . | +---+ | | Router +------+--< n
| | ,-. | | . | t
| (H2 )---------+ Entity | . | e
| `-' . | | . | r
| . | | . | f
| ,-. . | +------+--< a
| (Hn )---------+ | | c
| `-' +---+---+--------+---+ | e
| Internal Ingress | | .... | | s
| Interfaces/Networks | | | |
+------------------------+---+--------+----------+
| | |
v v v
External Ingress Interfaces
Figure 1: MANET Router
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
