Re: [v6ops] Operational Guidance for IPv6 Deployment inPredominantly IPv4 Sites - (pre-draft)

["Templin, Fred L" <[e-mail]>]

Hi Mark,

It sounds like what you'd prefer would be DHCPv6
over ISATAP interfaces. In that case, the routing
system matches up the (non-ISATAP) DHCPv6-delegated
IPv6 addresses with an ISATAP link-local address of
the host to which the address has been delegated.
We talk about how to do exactly that in Section
3.2.4 of 'draft-ietf-v6ops-tunnel-loops'.

So, this has come down to a DHCPv6 vs SLAAC bakeoff
on ISATAP links, I guess? I was told by an employee
of a major host implementation vendor that their
ISATAP host implementation does not do DHCPv6. But,
you list a number of reasons why DHCPv6 would be
beneficial.

This sounds like a recipe for a food-fight. Can I
run off to catch that train with you??

Fred
[e-mail] 

> -----Original Message-----
> From: Mark Smith 
> [mailto:[e-mail]] 
> Sent: Tuesday, April 12, 2011 4:02 PM
> To: Templin, Fred L
> Cc: [e-mail]
> Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment 
> inPredominantly IPv4 Sites - (pre-draft)
> 
> Hi Fred,
> 
> On Tue, 12 Apr 2011 15:07:24 -0700
> "Templin, Fred L" <[e-mail]> wrote:
> 
> > Hi Mark, 
> > 
> > > -----Original Message-----
> > > From: Mark Smith 
> > > [mailto:[e-mail]] 
> > > Sent: Tuesday, April 12, 2011 2:43 PM
> > > To: Templin, Fred L
> > > Cc: [e-mail]
> > > Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment 
> > > inPredominantly IPv4 Sites - (pre-draft)
> > > 
> > > Hi Fred,
> > > 
> > > On Mon, 11 Apr 2011 11:18:14 -0700
> > > "Templin, Fred L" <[e-mail]> wrote:
> > > 
> > > > Hello,
> > > > 
> > > > The following should not be construed as a draft, but
> > > > rather just a set of ideas that might be considered
> > > > for inclusion in a new or existing draft. Any
> > > > comments or suggestions?
> > > > 
> > > 
> > > I don't know if it has been though of before, however one 
> alternative
> > > use of ISATAP I've thought of is to facilitate IPv6 topology
> > > hiding. The underlying IPv4 addresses probably would expose 
> > > the network
> > > typology, however if they're RFC1918 ones, they'd be unreachable
> > > externally.
> > 
> > There is probably a discussion point here, but I'll
> > note that other IPv4-embedding mechanisms like 6to4
> > and 6rd are not shy about exposing IPv4 addresses
> > externally. Especially with 6rd, the IPv4 addresses
> > may be from the private internal IPv4 addressing realm
> > of the ISP, so there would seem to be precendence for
> > just letting the IPv4 addresses leak out.
> > 
> 
> I think people who're using those sorts of mechanisms probably aren't
> concerned about using topology hiding so much, or are aware that only
> one or a small number of public IPv4 addresses are exposed.
> 
> I'm imagining a conversation with people who like the topology
> hiding that IPv4 NAPT provides, and think they need IPv6 NAPT for the
> same reason. I think you could rebut that by saying that ISATAP could
> be used to make all IPv6 hosts appear to be attached to a single /64,
> also pointing out that ISATAP implementations are commonly available.
> However, when they find out that underlying IPv4 addresses 
> are embedded
> in the ISATAP addresses, they'll then say that thats still exposing
> IPv4 topology information that isn't exposed with IPv4 NAPT, and
> therefore ISATAP isn't adequate, and therefore they need IPv6 NAPT.
> 
> So I think ISATAP is nearly capable of providing IPv6 and underlying
> IPv4 topology hiding, as long as the exterior devices don't see the
> underlying IPv4 addresses. It has just occurred to me that ISATAP +
> stateful DHCPv6 addressing might achieve that. Do you know if that
> would work or has been implemented anywhere?
> 
> 
> > > Possibly this could be resolved by having only the ISATAP
> > > domain link-local addresses use IPv4 addresses, and then have 
> > > global ->
> > > link local IPv6 translation tables which are then used to 
> resolve a
> > > global IPv6 ISATAP host address which doesn't include an 
> interior IPv4
> > > host address into a ISATAP link local and then interior IPv4 
> > > address. As
> > > external parties would only use externally visible IPv6 
> addresses, the
> > > IPv4 topology would then be hidden as well.
> > 
> > I'm almost on-board with this, however I would not
> > want to see the site number all of its ISATAP host
> > interfaces with only link-local IPv6 addresses. Or,
> > maybe that's not what you were saying?
> > 
> 
> No, it was that the underlying IPv4 addresses were only 
> embedded in the
> link local addresses used within the ISATAP domain, and the 
> global IPv6
> addresses used within the ISATAP domain were generic (non-IPv4
> embedded) IPv6 addresses (e.g. SLAAC using some other non-IPv4 IID, or
> privacy addresses, or stateful DHCPv6 addresses).
> 
> To resolve the underlying IPv4 address for inbound packets, with these
> generic global IPv6 addresses, the look up mechanism would be -
> 
> 1. Match up the global IPv6 address to an ISATAP domain link-local
> address with the embedded IPv4 address.
> 2. Extract the IPv4 address from the link local address and use that
> for the encapsulating packet IPv4 destination.
> 
> > What I *could* see happening is for the ISATAP
> > router to maintain a translation table whereby
> > it translates the IPv6 address 2001:db8::[ISATAP]
> > coming from a host within the site to the IPv6
> > address 2001:db8::[EUI64] for communications with
> > hosts outside the site.
> 
> I think the drawback of that is that it is IPv6-to-IPv6 address
> translation with all the related issues of NAT.
> 
> > 
> > Even moreso, ISATAP hosts inside an enterprise
> > network are likely to need to go through an
> > enterprise-border proxy in order to talk to IPv6
> > servers out on the Internet, so the proxy itself
> > could do the translation as I suspect many IPv4
> > proxies currently do today.
> > 
> > Is that what you had in mind?
> > 
> > Thanks - Fred
> > [e-mail]
> > 
> 
> (got to rush off to catch my train!)
> 
> Regards,
> Mark.
>