Subject: [v6ops] Enterprises and draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat

From: Teco Boot <[email-masked]>
Date: Mon, 14 Nov 2011 08:29:57 +0100

In 6renum wg (enterprise renumbering), we have a need for egress router selection based on source address. This topic would be in scope of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But IMHO current version sticks to very small sites. Enterprises have often a multi-hop path between hosts and egress routers. Add such scenario in the document?

Current text and diagram in section 3.2 nicely explains the IPv4-NAPT approach. We already know how this works. Replace with something focussed on an IPv6 network?

Teco.

---

From: Fred Baker <[email-masked]>
Date: Mon, 14 Nov 2011 15:41:01 +0800

</chair>

> In 6renum wg (enterprise renumbering), we have a need for egress router selection based on source address. This topic would be in scope of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But IMH…

Why is exit routing not a routing problem? I would think it is an appropriate topic for a model such as draft-baker-fun-routing-class

> Current text and diagram in section 3.2 nicely explains the IPv4-NAPT approach. We already know how this works. Replace with something focussed on an IPv6 network?

That would be the province of tools like RFC 6296...

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 14 Nov 2011 15:47:53 +0800

On 11/14/11 15:41 , Fred Baker wrote:
>> In 6renum wg (enterprise renumbering), we have a need for egress
>> router selection based on source address. This topic would be in
>> scope of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But
>> IMHO current version sticks to very small sites. Enterprises have
>> often a multi-hop path between hosts and egress routers. Add such
>> scenario in the document?
> 
> Why is exit routing not a routing problem? I would think it is an
> appropriate topic for a model such as draft-baker-fun-routing-class

<troll>

there's always rh0...

>> Current text and diagram in section 3.2 nicely explains the
>> IPv4-NAPT approach. We already know how this works. Replace with
>> something focussed on an IPv6 network?
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 14 Nov 2011 15:56:15 +0800

>> appropriate topic for a model such as draft-baker-fun-routing-class

There is, if one knows what address to rh0 to; I don't know of any hosts that know that...

---

From: Teco Boot <[email-masked]>
Date: Mon, 14 Nov 2011 09:04:13 +0100

2011/11/14 Fred Baker <[email-masked]>

> > In 6renum wg (enterprise renumbering), we have a need for egress router
> selection based on source address. This topic would be in scope of
> draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But IMHO current version
> sticks to very small sites. Enterprises have often a multi-hop path between
> hosts and egress routers. Add such scenario in the document?
>

Sure. The BRDP-based routing model is fun also, although less fundamental.

I don't care v6ops or 6renum produces a gap analysis doc to kick some wg in
routing area.

> > Current text and diagram in section 3.2 nicely explains the IPv4-NAPT
> approach. We already know how this works. Replace with something focussed
> on an IPv6 network?
>

I thought the goal of this draft is try to avoid?

Teco.

---

From: Teco Boot <[email-masked]>
Date: Mon, 14 Nov 2011 09:08:45 +0100

2011/11/14 Joel jaeggli <[email-masked]>

> > appropriate topic for a model such as draft-baker-fun-routing-class

O yes. Or take another approach: L3-switches could be nice tunnel
endpoints. Often, CPU is idle on these boxes, so I don't expect objections.

---

From: Fred Baker <[email-masked]>
Date: Mon, 14 Nov 2011 16:44:14 +0800

On Nov 14, 2011, at 4:08 PM, Teco Boot wrote:

> O yes. Or take another approach: L3-switches could be nice tunnel endpoints. Often, CPU is idle on these boxes, so I don't expect objections. 

:-)