Kurt Erik Lindqvist | 1 Feb 11:06 2003
Picon

Re: agenda items for v6ops in San Francisco


>> As a general note, I think we should try to discuss "transition
>> architecture" in a more aggregated fashion: now it has spread all 
>> over the
>> analysis documents (consider e.g. NAT/PT vs dual-stack etc.).
>>
>> One way trying to get some coherence here might be to try to have some
>> discussion (like 10-20 mins) on some specific topics before (or 
>> after) the
>> scenarios.
>
> this has some appeal.  also, i think a generic discussion of they 
> types of
> security issues raised by transition mechanisms might be worthwhile.  i
> suspect that we would benefit from a common and consistent story for 
> both of
> these.
>

I agree with Randy and Pekka, but a small remark - what do we want the 
outcome to be? An I-D containing an overview aka the site-local I-Ds?

- kurtis -

Alain Durand | 3 Feb 21:39 2003
Picon

Re: agenda items for SF ? ISPs document


MicklesCK wrote:

> We do not have an author for the datacenter
>section.  I propose we drop the additional datacenter 
>section since, as I pointed out at the interim meeting, there
>would be overlap with the Enterprise draft.
>
One point I would like to raise about IPv6 in the datacenter
is load balancers. They basically are NAT boxes dispatching the traffic
to a number of servers. Are we going to need NATv6 afterall?

Anyway, I think this concern is specific to the big datacenter
and should be addressed in the ISP scenario.

    - Alain.

Roy Brabson | 3 Feb 22:25 2003
Picon

Re: agenda items for SF ? ISPs document

> One point I would like to raise about IPv6 in the datacenter
> is load balancers. They basically are NAT boxes dispatching the traffic
> to a number of servers. Are we going to need NATv6 afterall?

I guess that depends on the load balancing device.  I'm familiar with many 
which do not use NAT for dispatching traffic.  Instead, the load 
balancer(s) advertise a server address to which client traffic is 
directed.  Each server which is part of the load balancing group also 
defines the same address, but in a manner such that the address is not 
advertised if the server is running dynamic routing protocol.  Depending 
on the proximity of the load balancer to the servers, the load balancer 
may rewrite the destination MAC address to direct the packet to the chosen 
server or may use some form of tunneling (such as GRE) to send the packet 
to the chosen server.  Neither approach requires the use of NAT.

> Anyway, I think this concern is specific to the big datacenter
> and should be addressed in the ISP scenario.

I don't agree, at least not for the enterprise customers I work with. Many 
use and deploy load balancers within the datacenter and do not rely on the 
ISP to provide this type of service.  I would see this as belonging within 
the Enterprise scenario document instead of the ISP scenario document.

Roy

Cleve Mickles | 3 Feb 23:08 2003
Picon

RE: agenda items for SF ? ISPs document


I've asked existing L4 vendors about this over the past year
and even though this is widely done in the IPv4 world, the vendors
don't have any plans to add this IPv6 functionality until market
forces dictate it.

From what I see today, the only alternative is to use DNS
to load balance.  We know using DNS to load balance won't
give us the best performance.  We also will probably run into
the same UDP packet size limits with IPv4 DNS rotors.  It
does however gives us something to work with until we have
a critical mass of IPv6 capable servers which we can then go
to the vendors and ask them to give us the functionality.

NATv6 is a possible solution and the WG may decide that is the best
recommendation in the long run.  The vendors will probably end up doing
their own proprietary solutions as I have not seem many interoperable L4
load balancers to date.  I would assume the work on NATv6 would be done
in the IPv6 WG.

Whether we describe this in the ISP document or Enterprise document is up
to the WG.  At the interim meeting the WG wanted a datacenter description
in both, at last IETF the status of whether to include datacenters in the
ISP scenarios was inconclusive.  In any event, no authors have come forward
to work on the section so it will not be included unless the WG feels it
should
be retained and someone steps forward.

Cleve...

(Continue reading)

Brian E Carpenter | 4 Feb 14:57 2003
Picon

Re: agenda items for SF ? ISPs document

Cleve Mickles wrote:
...
> NATv6 is a possible solution and the WG may decide that is the best
> recommendation in the long run.  

Only over numerous dead bodies. As Roy Brabson pointed out, this is
by no means a requirement for server load balancing (and wouldn't
be too helpful if you happened to be using IPSEC or any other
address-sensitive protocol). Also, I can't see why it would become
an IETF recommendation anyway. IPv4 load balancing is widely
implemented without any help from the IETF. We just need to avoid
making it harder.

Certainly, this topic belongs in the enterprise scenario.

    Brian

Keith Moore | 4 Feb 00:03 2003
Picon

Re: agenda items for SF ? ISPs document

> NATv6 is a possible solution and the WG may decide that is the best
> recommendation in the long run. 

It would be very helpful to distinguish between the use of network address
translation for the purpose of load-balancing within a network of hosts that
are dedicated to support specific applications that are known to be compatible
with this practice, and network address translation that is imposed on a set
of hosts that are used for a variety of purposes and are expected to support
an open-ended set of applications.

NAT can work well for specific, carefully chosen cases.  It cannot be made to
work well in general.

Keith

JORDI PALET MARTINEZ | 4 Feb 19:21 2003
Picon

Re: agenda items for SF ? ISPs document

IPsec, yes, this could be a problem, but as I know the load balancers keep all the session (security
association then ?) to the same
"server", as otherwise, the database access, bank transactions, and others, will be broken.

Anyway, may be there is another way to do load-balancing using anycast, but not sure if the actual
architecture supports it, may be
again it will depend on how the load-balancers implement it.

Regarding if ISP or Enterprise, and ISP "hosting" services (so offering load balancing for large number of
users), could be always
considered an Enterprise ... but I feel that the boundary between both is not clear enough among both design teams.

Regards,
Jordi

----- Original Message -----
From: "Brian E Carpenter" <brian@...>
To: <micklesc@...>; <v6ops <at> ops.ietf.org>
Sent: Tuesday, February 04, 2003 2:57 PM
Subject: Re: agenda items for SF ? ISPs document

> Cleve Mickles wrote:
> ...
> > NATv6 is a possible solution and the WG may decide that is the best
> > recommendation in the long run.
>
> Only over numerous dead bodies. As Roy Brabson pointed out, this is
> by no means a requirement for server load balancing (and wouldn't
> be too helpful if you happened to be using IPSEC or any other
> address-sensitive protocol). Also, I can't see why it would become
(Continue reading)

Tony Hain | 5 Feb 02:20 2003
Picon

RE: DNS support for IPv6

Fernando Gont wrote: 
> Hi,
> 
> I'm just about to write a brief explanation about the RRs 
> that need to be 
> added to the ones described in RFC 1034 / 1035, in order to 
> add support for 
> IPv6.
> 
> I've read RFC 3363, and it recommends that RFC 1886 stay on 
> standards track 
> and be advanced, and to move RFC 2874 to Experimental status.
> 
> Shall I make comments on AAAA records, and don't even mention 
> A6 records?
> 
> About address mapping, RFC 3152 says IP6.ARPA should be used, 
> instead IP6.INT. The same here: shall I omit the description 
> of IP6.INT, or it is still 
> being used, and so, I should describe it?
> 

I believe that at this point for operational deployments, it is
appropriate to leave out A6 & IP6.INT. If you were going to discuss them
at all, an appendix comment about their current status as experimental
and deprecated might reduce some confusion. 

Since this is more of an operational nature, it should probably be
discussed on v6ops (cc'd).

(Continue reading)

Jason Goldschmidt | 5 Feb 03:24 2003
Picon

Re: agenda items for SF ? ISPs document


JORDI PALET MARTINEZ wrote:
> IPsec, yes, this could be a problem, but as I know the load balancers keep all the session (security
association then ?) to the same
> "server", as otherwise, the database access, bank transactions, and others, will be broken.
> 
> Anyway, may be there is another way to do load-balancing using anycast, but not sure if the actual
architecture supports it, may be
> again it will depend on how the load-balancers implement it.
> 
> Regarding if ISP or Enterprise, and ISP "hosting" services (so offering load balancing for large number
of users), could be always
> considered an Enterprise ... but I feel that the boundary between both is not clear enough among both
design teams.

I agree that such a scenario needs documenting by one of the design 
teams and that the boundary is not clear.  If people want it documented 
sooner, rather then later, the ISP design team would be the best 
candidate.  Simply because they currently are showing greater momentum 
in producing a completed set of documents.

thanks,

-Jason

> 
> Regards,
> Jordi
> 
> ----- Original Message -----
(Continue reading)

Margaret Wasserman | 5 Feb 03:45 2003

Re: (ngtrans) ngtrans to finally be removed as a wg from IETF web pages


Hi All,

To elaborate a bit on Bob's message (attached)...

The secretariat will be taking the following steps today or
tomorrow to complete the process of shutting down the ngtrans
WG:

         - Removing the ngtrans WG charter page from the
                 list of active OPS area WGs, and moving
                 it to the list of concluded WGs.
         - Changing the ownership of all ngtrans I-Ds from
                 ngtrans to "none" (returning them to
                 individual submission status).  The
                 drafts will not be renamed, but further
                 updates may not be issued under the
                 draft-ietf-ngtrans-* names.
         - Removing the ngtrans WG from the milestone
                 tracker, and performing other clean-up.

As Bob stated, the shutdown of the ngtrans WG will have no affect
on the ngtrans mailing list.

Please let me know if you have any questions regarding this
process.

Margaret
Former ngtrans co-chair

(Continue reading)


Gmane