Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault]

From: Alain Durand <[email-masked]>
Date: Fri, 8 Apr 2005 16:53:52 -0700

[resent for wrong v6ops list address]

The tracker says:

"[david] The working group has to decide whether this document really 
needs to
published.
In any case it needs more work by the working group before it can be
published."

I can understand the first part, but not the second. Could the AD or 
the chairs clarify
what further work is necessary?

	- Alain.

>  -------- Original Message --------
>
>  Subject:
>  draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault
>
> Date:
>  Mon, 28 Mar 2005 08:13:02 -0800
>
> From:
>  Baker Fred <[email-masked]>
>
> To:
>  [email-masked] <[email-masked]>, [email-masked] 
> <[email-masked]>, [email-masked] 
> <[email-masked]>
>
> CC:
>  Lindqvist Erik Kurt <[email-masked]>, David Kessens 
> <[email-masked]>, "[email-masked]" <[email-masked]>
>
>
>
> The IESG has returned the onlinkassumption and v6onbydefault drafts to
> the working group, asking us whether it really needs to be published,
> and if so to finish them.
>
> https://datatracker.ietf.org/public/pidtracker.cgi?
> command=view_id&dTag=11066&rfc_flag=0
> https://datatracker.ietf.org/public/pidtracker.cgi?
> command=view_id&dTag=11045&rfc_flag=0
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 8 Apr 2005 17:41:52 -0700

On Apr 8, 2005, at 4:39 PM, Alain Durand wrote:
> the chairs clarify what further work is necessary?

I have asked David and not gotten a reply.

In the working group meeting in March, both my minuted and Mikael's  
note that David stated that he felt that publication of these drafts  
were unnecessary once the problems they addressed were fixed in the  
network. Your comment in the same discussion was that documenting the  
issues had validity beyond the scope of the timeline.

As you note in response to the minutes,

>> The on-link assumption draft will be published with  
>> draft-ietf-ipv6-rfc2461bis, which removes that assumption.
>
> draft-ietf-ipv6-rfc2461bis remove the on-link assumption text but does  
> not provide the rationale for the change.

Let me play devil's advocate for a moment:  
draft-ietf-ipv6-rfc2462bis-07.txt is right now awaiting an updated  
draft (see  
https://datatracker.ietf.org/public/pidtracker.cgi? 
command=view_id&dTag=11541&rfc_flag=0 for comments ). If this is the  
primary reason for publishing this document, then maybe some text  
(comparable to Allison's other 'discuss' questions) could simply be  
handled there? If not, please advise specifically what additional  
issues are covered?

 From my perspective, I don't have a problem sending on-link-assumption  
back with an appropriate report and publishing it with rfc2461bis. But  
I think I need to ask you to compare notes with the authors of the  
other and ensure that the two drafts are entirely in sync.

v6onbydefault is rather another story from my perspective. Many end  
systems are now coming with IPv6 on by default, and software images are  
available from most common routers (even Linksys, which normally  
doesn't do anything without a groundswell customer demand). For  
routers, one also wants to design the network and appropriately  
configure them, so they don't usually come with even IPv4 on by default  
in a routing configuration. So if you were presenting arguments for  
doing so, the arguments are OBE. Willing to be told otherwise, but here  
my advice would be to take "yes" as an answer form the equipment and OS  
folks...

---

From: Alain Durand <[email-masked]>
Date: Fri, 8 Apr 2005 23:38:17 -0700

On Apr 8, 2005, at 5:41 PM, Fred Baker wrote:
>> draft-ietf-ipv6-rfc2461bis remove the on-link assumption text but  
>> does not provide the rationale for the change.
>

I'm not sure I follow you... The change is in 2461bis, not 2462bis.

> >From my perspective, I don't have a problem sending  
> on-link-assumption back with an appropriate report and publishing it  
> with rfc2461bis. But I think I need to ask you to compare notes with  
> the authors of the other and ensure that the two drafts are entirely  
> in sync.

The relevant change in rfc2461bis is the deletion of the following  
sentence in the 2nd paragraph of section 5.2:
--> If the Default Router List is empty, the sender assumes that the  
destination is on-link.
as is suggested in the onlink asumption draft...

One think we could do is re-spin the draft to change the tense of some  
sentences
to make it more sound "this is why it was done" rather "this is how and  
why it should be done"
As the draft has expired, a new rev is needed anyway.

> systems are now coming with IPv6 on by default, and software images  
> are available from most common routers (even Linksys, which normally  
> configure them, so they don't usually come with even IPv4 on by  
> default in a routing configuration. So if you were presenting  
> arguments for doing so, the arguments are OBE. Willing to be told  
> otherwise, but here my advice would be to take "yes" as an answer form  
> the equipment and OS folks...

Well, I used to work for an OS vendor, and my co-author still do.
Maybe it is a conservative, risk adverse one, but we were worried
that shipping our stack with v6 on by default would generate
a large number of service call, so all necessarily precautions needed
to be taken. We wrote the draft in that spirit.

Let's look at the table of content and see what is still relevant
There are essentially two parts in the document:

Things that need to be resolved in the host stacks:
2.  No IPv6 Router . . . . . . . . . . . . . . . . . . . . . . . .  3
      2.1   Problems with Default Address Selection for IPv6 . . . . .  3
	-> still an issue, but maybe this should be redirected
	     as a separate document toward an update of RFC3484.
      2.2   Neighbor Discovery's On-Link Assumption Considered
            Harmful  . . . . . . . . . . . . . . . . . . . . . . . . .  5
	-> may be obe by onlinkasuption draft
      2.3   Transport Protocol Robustness  . . . . . . . . . . . . . .  6
	-> Still an open issue, but addressed in the transport wg

Things that need to be resolved in the network:
    3.  Other Problematic Scenarios  . . . . . . . . . . . . . . . . .  6
      3.1   IPv6 Network of Smaller Scope  . . . . . . . . . . . . . .  6
        3.1.1   Alleviating the Scope Problem  . . . . . . . . . . . .  7
      3.2   Poor IPv6 Network Performance  . . . . . . . . . . . . . .  7
      3.3   Security . . . . . . . . . . . . . . . . . . . . . . . . .  8
        3.3.1   Mitigating Security Risks  . . . . . . . . . . . . . .  8
    4.  Application Robustness . . . . . . . . . . . . . . . . . . . .  9

Those last 2 sections are highlighting general deployment problems, not  
something special
for v6 on by default.

I can be convinced that if we put the issue with RFC3483 aside,
the first part is now largely obe.
Maybe we could re-focus the id on this second part if the wg thinks  
there is value here...

	- Alain.

---

From: Fred Baker <[email-masked]>
Date: Sat, 9 Apr 2005 14:14:22 -0700

> I'm not sure I follow you... The change is in 2461bis, not 2462bis.

Sorry, you're correct. That said, this merely amplifies the question - 
and understand that I am simply asking a question. In English, we often 
say that "there is more than one way to skin a cat". David is saying 
that wiith 2461bis and adoption of the proposal in it by various 
vendors, there may be no real need to publish this document. Is there 
another way to document the information that might be superior? Or is 
publishing this one the superior process? That's the question.

So 2461bis has not even been submitted to the ADs (2462bis has been 
submitted and sent back for revision). Your assertion is that at least 
part of the problem is that 2461bis doesn't contain a discussion of why 
a certain change was made. Well, would it be worthwhile to put that 
discussion into 2461bis, perhaps in an appendix? Or are there other 
reasons to publish specifically this document?

As to the following, yes, the 3484 comment might go in a separate 
document and then refocus v6onbydefault to the second topic if the 
remainder of the first part is OBE. I'm not sure the tense change in 
on-link-assumption is worth the effort. I would focus on publishing it 
or not publishing it - unless someone else in the WG has a different 
perspective.

> to make it more sound "this is why it was done" rather "this is how 
> and why it should be done"
>> otherwise, but here my advice would be to take "yes" as an answer 
>> form the equipment and OS folks...
>
> Those last 2 sections are highlighting general deployment problems, 
> not something special
> for v6 on by default.
>

---

From: Pekka Savola <[email-masked]>
Date: Sun, 10 Apr 2005 10:24:52 +0300 (EEST)

On Sat, 9 Apr 2005, Fred Baker wrote:
> So 2461bis has not even been submitted to the ADs (2462bis has been submitted 
> and sent back for revision). Your assertion is that at least part of the 
> problem is that 2461bis doesn't contain a discussion of why a certain change 
> was made. Well, would it be worthwhile to put that discussion into 2461bis, 
> perhaps in an appendix? Or are there other reasons to publish specifically 
> this document?

IMHO, the description is too long to be contained in the appendix. 
However, I do think that 2461bis appendix should mention that the 
assumption was removed and refer to this document.

I think it is important to document this kind of background, so that 
vendors realize why they should be removing the onlink assumption 
(when updating their 2461 implementation to 2461bis they might not 
bother or even notice it otherwise).  A document like this also serves 
as a way to document the arguments if someone later on brings this up 
again.

But see below.

> As to the following, yes, the 3484 comment might go in a separate document 
> and then refocus v6onbydefault to the second topic if the remainder of the 
> first part is OBE. I'm not sure the tense change in on-link-assumption is 
> worth the effort. I would focus on publishing it or not publishing it - 
> unless someone else in the WG has a different perspective.

I believe it is useful to have a document which provides brief 
discussion / pointers as well (first category).  I don't have strong 
preference whether onlink-assumption could be covered in this 
document, not a separate document.  But it seems to me that the log of 
major changes / issues that v6ops has brought up should be described 
somewhere.

>> not something special for v6 on by default.
>> 
>> I can be convinced that if we put the issue with RFC3483 aside, the 
>> first part is now largely obe. Maybe we could re-focus the id on 
>> this second part if the wg thinks there is value here...

As above, I think there is value in also describing the background 
and/or providing points to issues which have been fixed or are in the 
process of being fixed.  This could be used by a user with an older 
implementation so see whether he's experiencing any of the issues 
described in the document.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian Haberman <[email-masked]>
Date: Sun, 10 Apr 2005 15:10:01 -0400

Hi Fred,

On Apr 9, 2005, at 17:14, Fred Baker wrote:

> and understand that I am simply asking a question. In English, we 
> often say that "there is more than one way to skin a cat". David is 
> saying that wiith 2461bis and adoption of the proposal in it by 
> various vendors, there may be no real need to publish this document. 
> Is there another way to document the information that might be 
> superior? Or is publishing this one the superior process? That's the 
> question.
>
> part of the problem is that 2461bis doesn't contain a discussion of 
> why a certain change was made. Well, would it be worthwhile to put 
> that discussion into 2461bis, perhaps in an appendix? Or are there 
> other reasons to publish specifically this document?

I would like to see the rationale for the change documented in some 
form.
My preference would be to include it in 2461bis as an appendix (in a 
less
verbose form).  That way, people will be able to see why the change was
made so we don't re-visit the issue over and over and over...

And as co-chair of IPv6 WG, I can help coordinate that work if the v6ops
determines that is the path we want to follow.

Regards,
Brian

---

From: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Mon, 11 Apr 2005 11:09:31 +0530

Hi all,
The following text in RFC 2461bis Appendix A will also need changes for
onlink assumption:
"   If a multihomed host fails to receive Router Advertisements on one or
   more of its interfaces, it will not know (in the absence of
   configured information) which destinations are on-link on the
   affected interface(s).  This leads to a number of problems:

     1) If no Router Advertisement is received on any interfaces, a
        multihomed host will have no way of knowing which interface to
        send packets out on, even for on-link destinations.  Under

        similar conditions in the non-multihomed host case, a node
        treats all destinations as residing on-link, and communication

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        proceeds.

"

----- Original Message ----- 
From: "Brian Haberman" <[email-masked]>
To: "Fred Baker" <[email-masked]>
Cc: "David Kessens" <[email-masked]>; <[email-masked]>
Sent: Monday, April 11, 2005 12:40 AM
Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and
draft-ietf-v6ops-v6onbydefault]

---

From: Fred Baker <[email-masked]>
Date: Sun, 10 Apr 2005 10:07:56 -0700

> as a way to document the arguments if someone later on brings this up 

OK. Lets make sure that the normative document and the explanatory 
document point to each other and send them in together. I will 
coordinate with Bob+Margaret on coordination if you folks would be so 
kind as to get the document sorted out.

---

From: David Kessens <[email-masked]>
Date: Tue, 12 Apr 2005 22:25:27 -0700

Alain,

On Fri, Apr 08, 2005 at 04:53:52PM -0700, Alain Durand wrote:
> 
> "[david] The working group has to decide whether this document really needs to 
> published. 
> I can understand the first part, but not the second. Could the AD or the chairs clarify 

The revision should be focussed on making it more clear that this is
document contains background/historic information on why this change
was made. It basically needs adaptation to the new current situation.
For example, it has a section 'Proposal for change' while we are not
talking about a proposal anymore.

I understand that documenting this kind of things are very nice to
have. However, I could also imagine that you (and the working group)
rather spend time on more pressing technical issues that are still in
actual need of resolution. As documented in the tracker, this decision
needs to be made by the working group, not by me. 

I hope this helps,

David Kessens
---

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 20 Apr 2005 16:56:17 +0900

>>>>> On Mon, 11 Apr 2005 11:09:31 +0530, 
>>>>> Radhakrishnan Suryanarayanan <[email-masked]> said:

I've already pointed it out in the ipv6 list, and the document editor
acknowledged that (so the next version of the draft will fix it).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]