Subject: (ngtrans) ngtrans agenda planning for Minneapolis

From: Bob Fink <[email-masked]>
Date: Tue, 02 Mar 1999 17:26:40 -0800

NGtrans Folk,

The current scheduling for ipv6 (IPng & NGtrans WG) sessions in Minneapolis is:

  MONDAY, March 15, 1999 for IPng WG meetings

    0930-1130  IPng WG 1st session

    1930-2200  IPng WG 2nd session

  TUESDAY, March 16, 1999 for NGtrans WG meetings

    0900-1000  NGtrans WG 1st hour

    1015-1115  NGtrans WG 2nd hour

    1545-1645  NGtrans WG 3rd hour

    1700-1800  NGtrans WG 4th hour

Note that both IPng and NGtrans are 4 hours long in total, although NGtrans
gets a little extra time as there are short breaks between the one-hour
back-to-back sessions. We will probably use this time at least between the
3rd and 4th hour.

Based on the Grenoble Interim NGtrans meeting, conversations on the list
since then, and conversations with our area directors and other IESG folk
off the list, Tony and I see the agenda breaking out over the four one-hour
time slots as follows:

1st hour: refine 6to4 enough to know if we are going to make use of it for
transition, thus readying it for PS and enough solid support and progress
that we could request a TLA for it. This may be our most important and
immediate work in ngtrans as there seems to be strong consensus building
that 6to4 could really help the transition. But whatever the outcome, we
need to decide what to do with it, else it could lead us down wasteful
paths. Brian Carpenter and/or Keith Moore will lead this discussion.

2nd hour: two parts, 45 and 15 mins each:

45 mins: Refine the goals and plan for the roadmap document(s). There are
several folk that have offerred to help with the roadmap documents, so if
any of you would like to help organize this part of the meeting, please
send email to Tony and Bob with your ideas. Failing that, Tony and Bob will
organize and run the session.

15 mins: Reintroduce plans for making the 6bone more robust (I'm hoping
that this time around the general consensus will be to come down hard on
the side of making the 6bone routing much more robust and hardened). In the
past, there was unwillingness to do this as it discouraged folks from
joining in. Bob Fink will kick this one off, but if others wish to speak on
this they should send Bob email with their ideas.

3rd/4th hours: broken into approx. 25-minute mini-sessions to work on the
existing transition mechanisms/tools draft to see if they can be readied
for PS, or if they should be submitted as Experimental or Informational. 

The list of submitted drafts we have worked on to date are: SIIT, NAT-PT,
AIIH, Bump-in-the-stack (BIS), and DTI. We would like at least one of the
authors of each of these drafts to volunteer to lead their respective
mini-session. Please contact Tony and Bob to "volunteer" for this. 

One idea (from Jim Bound) on how to start each mini-session would be for
the author(s) to prepare a short section called "Transition Assumptions"
for their respective drafts. This will help readers understand the scope,
purpose, and focus of a particular mechanism. It also will focus debate and
hopefully permit work to be discussed more efficiently in the context of
the assumption by the authors. For now, assume that this will be required
for the each mini-session/draft.

Note that this is a very full agenda, so we will discourage taking other
topics outside of these areas. If you believe you have a persuasive case to
make for getting some time at the meeting outside of our agenda topics
above, please email both Tony and Bob with your proposal/argument. We are
already foregoing discussions on reporting the Grenoble meeting, reporting
on a revised charter/milestones, and other business that can be handled on
the list. 

With all your help we will have a successfull meeting!

Thanks,

Tony and Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Mar 1999 10:59:37 +0000

The 6to4 draft has still not popped out, apparently,
so I have put it at
http://www.hursley.ibm.com/~bc/draft-ietf-ngtrans-6to4-01.txt

This URL will only work until the draft is announced by the
Internet Drafts folk. Don't bookmark it!

   Brian

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 4 Mar 1999 00:07:48 -0800 (PST)

Brian,

In section 6.1 you say there is no setup needed.
In section 5 you say that multicast can be provided by e.g PIM-SM
(I assume you mean IPv6 PIM-SM.)

PIM needs a unicast routing protocol to provide the base for the RPF.
Are you asserting that all 6to4 egress/ingress routers should assume
they are directly attached to <FP=001, TLA624>/16 prefix i.e. inject
such a unicast route into their "site" for the purposes of multicast routing?
That isn't clear from the document.

When it comes to transmitting multicast packets from the egress router
I don't see anything in the spec that helps it determine where to
send the packets. So short of sending 2^^32 packets to all possible IPv4 
addresses what do you propose?

In section 6.2 you say:
   An IPv6 router willing to act as a relay from native IPv6 to the 6to4
   address space advertises a route to {FP=001,TLA=TLA624}/16 into the
   native IPv6 routing system, and whatever other native IPv6 prefixes
   are appropriate on its 6to4 interface.

In don't understand hpw you can do the second part. You don't have a routing
protocol running over the 6to4 interface so how can you advertise routes
on that interface?

What am I missing?

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Mar 1999 10:22:34 +0000

Erik,

These are points I have been worrying about; as you have detected,
the text is hand waving inserted to raise the issues rather than
resolve them. We need help in this area.

    Brian

---

From: Kazuaki Tsuchiya <[email-masked]>
Date: Thu, 04 Mar 1999 20:40:54 +0900

Dear Ngtrans folks,

At 17:26 99/03/02 -0800, Bob Fink wrote:
Bob> NGtrans Folk,
Bob> 
Bob> The current scheduling for ipv6 (IPng & NGtrans WG) sessions in
Minneapolis is:
Bob> 
Bob>	<omit>
Bob>
Bob> 3rd/4th hours: broken into approx. 25-minute mini-sessions to work on the
Bob> existing transition mechanisms/tools draft to see if they can be readied
Bob> for PS, or if they should be submitted as Experimental or Informational. 
Bob> 
Bob> The list of submitted drafts we have worked on to date are: SIIT, NAT-PT,
Bob> AIIH, Bump-in-the-stack (BIS), and DTI. We would like at least one of the
Bob> authors of each of these drafts to volunteer to lead their respective
Bob> mini-session. Please contact Tony and Bob to "volunteer" for this. 
Bob> 

I'll take charge of BIS.
# But I'm anxious about my poor English.
# Can anyone help me!

Best regards.
-- Kazuaki Tsuchiya.

--------------------------------------------------------
Kazuaki Tsuchiya (E-mail:[email-masked])
  Hitachi, Ltd.  Server & Network Development Division
    Phone:+81-462-32-2111(ex.2458)   Fax:+81-462-35-8324

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Mar 1999 16:29:11 +0000

As requested in today's NGTRANS session here are (some of)
the issues on draft-ietf-ngtrans-6to4-01.txt

1. concerns about multicast (see Erik's comment below)- must
   avoid the NBMA swamp.
2. not only does a relay router need a route to a native IPv6 router,
   but there must be a route in the other direction. This is just
   the same as a configured tunnel (but it is in effect a tunnel
   to a whole 6to4 cloud, not to a single site). Also what routing
   protocol runs between the relay router and the native router?
3. need more illustrations and examples in the draft,
   more worked out examples on routing in particular, and more
   motivation for why it's a useful tool in the toolkit.
4. a possible model is using 6to4 to create a virtual IPv6 ISP, i.e.
   the relay router is not on a 6to4 user site but ISP-operated.
5. concerns about incongruent routing between IPv6 and IPv4 leading
   to traffic crossing the same path twice.
6. objections to specifying address selection algorithm.
7. observation that configured tunnels can also co-exist
   with IPv4 NAT.
8. suggestion that IPv4 address used to generate IPv6 prefix should
   be inverted to completely eliminate risks of v6 routing table
   pollution.

The consensus was to expand and develop the draft, so further
comments are welcome.

 --  Brian

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 16 Mar 1999 09:23:26 +0100

>the issues on draft-ietf-ngtrans-6to4-01.txt

Some comments below - these may be completely naive.....
>   protocol runs between the relay router and the native router?

Why should 6to4 care what the routing protocol is?

>   the relay router is not on a 6to4 user site but ISP-operated.

The relay router has to have an IPv4 address to get the packets at,
I think; wouldn't that make it a "6to4 user site" by definition?

>   to traffic crossing the same path twice.

Probably unavoidable. And we've done this in every multiprotocol use
so far (MBONE, 6Bone, IP-over-X25, IP-over-ATM); why should 6-to-4 be
different?

>   be inverted to completely eliminate risks of v6 routing table

Grumble. I think it's too early to say that injecting sub-v4 routes
into v6 will *never* be useful.

>> That isn't clear from the document.

Seems to me it wouldn't work otherwise.
Also, the default route must be injected into sites that use 624 to get
to the "real" v6 network.

>> addresses what do you propose?

Wouldn't the egress(?) router treat the IPv4 cloud (in this sense) as 2^^32
tunnels, and only forward the packet to those IPv4 addresses that it had
seen JOINs from?
 
Seems to me I know what the router should do, so it's just a matter of
bending the words to do what I want them to do (DVMRP would NOT work.....)

                    Harald
-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]