RE: DKIM Signatures now being applied to IETF Email

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
> t.petch
> Sent: Saturday, July 30, 2011 3:26 AM
> To: Barry Leiba
> Cc: ietf
> Subject: Re: DKIM Signatures now being applied to IETF Email
> 
> Sadly, I do not see it being used in the mailing lists where an
> organisation is sending me directly data I would like to be able to rely on
> - which I think fits the applicability well - and instead, I see it
> being used on a mailing list such as those in the IETF where I
> believe that the costs outweigh the benefits - and I have no choice
> about that:-(.

There has been some post-DKIM talk recently about the idea of "transient 
trust", wherein (to use this example) ietf.org would verify the signature on an 
arriving list submission, attach an RFC5451 header field that indicates the 
results of that verification, then send the message out to the list with that 
added field and a new ietf.org signature that "covered" it.  Then, if you 
decide to believe ietf.org's claims about the original signature, you know more 
than you would otherwise.

This hasn't been widely deployed yet, but some big email providers are 
currently playing with the idea.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART last call review of draft-yevstifeyev-ion-report-06

[Roni Even]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-yevstifeyev-ion-report-06

Reviewer: Roni Even

Review Date:2011-7-31

IETF LC End Date: 2011-8-9

IESG Telechat date: 

 

Summary: This draft is ready for publication as an informational RFC.  

 

Major issues:

 

Minor issues:

 

I read in section 3.2 

"The IESG has determined that IONs will not be used in the future.It is
clear that the IESG, IAB, and IAOC need the ability to   publish documents
that do not expire and are easily updated. Information published as web
pages, including IESG Statements, are  sufficient for this purpose."

 

I was wondering that since the ION process required approval for the
document to be published, what will be the approval process when using web
pages. It is probably not part of this document but it is just a question
and I see no problem with publishing this document.

 

 

Nits/editorial comments:  

 

 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Brian E Carpenter]

Hi Pete,

On 2011-07-31 04:55, Pete Resnick wrote:
...
> I *really* want an answer to the issue that Scott raises. Eric and Brian
> each refer to a "baby step". A baby step toward what exactly?
> 
> If the answer is simply, "to align documentation with current
> procedure", that's fine, but then I want to know: a) Why is it useful
> and positive to line up documentation with current procedure? That is,
> what are we gaining by publishing this? 

I believe that the present situation is confusing both to IETF newcomers
(who may falsely believe that the IETF actually follows the 3 stage process)
and, worse, confusing to users of IETF standards (who may falsely believe
that a document isn't useful until it's advanced). We, and those users,
gain by reducing the confusion. (Note: I did not write "eliminating the
confusion".)

> and b) This document is
> identical to neither 2026 *nor* current procedure, so how is it
> accomplishing the goal of aligning with current procedure anyway?

It defines a practice which is *very* close to present practice,
apart from a minor name change. I think that's the best we can do,
but that's why it's a baby step, not a no-op.

> 
> If the answer is, "Yes, this document will cause a change in the percent
> of Proposed Standards that move up", then I want to know "How?", because
> like Scott, I haven't heard the answer stated in this dicussion.

It might cause a change, simply because the effort of making the single
move PS->IS will get you to the end state, whereas previously you had
to make two efforts, PS->DS->STD. But only time will tell if this changes
our collective behaviour.

   Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: What is Native IPv6

[Philip Homburg]

In your letter dated Sat, 30 Jul 2011 11:39:53 -0700 you wrote:
>6RD is not a last mile solution. With the existing levels of IPv6 traffic, an 
>ISP would deploy a couple of 6RD relays at their main IX. In a country such as
> France, it means that a 6RD customer in Nice would see their IPv6 traffic bei
>ng encapsulated all the way to Paris over IPv4 crossing the entire ISP's netwo
>rk for some 400 miles. In Spain, the really native part of the traffic would p
>ossibly start in Madrid.
>
>Imagine 2 customers in Barcelona, who are with two different ISPs using 6RD. T
>he 6RD relays are in Madrid for both, likely not much more than a few miles aw
>ay or even possibly in the same IX (I don't know the details of IXes in Madrid
>). The 6RD traffic from one goes over IPv4 all the way to Madrid, then goes na
>tive for a few miles to the other ISP's 6RD relay, then back over IPv4 to Barc
>elona. This is not native.

So, 6rd is bad because it allows an ISP to deploy it in a sub-optimal way.
Wow, if that how we are going to judge protocols then we can just as well go
home.

If the existing levels of IPv6 traffic were a reason to install just one 6rd
box for an entire country then expecting that ISP to deploy native IPv6 would
be extremely unrealistic.

And even if an ISP would do that. The round trip latency between Barcelona and
Madrid is likely to be in the order of 5ms. There are DSL error correcting
settings that have much impact than that.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[John Leslie]

Pete Resnick  wrote:
> 
> I *really* want an answer to the issue that Scott raises. Eric and Brian 
> each refer to a "baby step". A baby step toward what exactly?
> 
> If the answer is simply, "to align documentation with current 
> procedure", that's fine, but then I want to know:
> a) Why is it useful and positive to line up documentation with current
>procedure? That is, what are we gaining by publishing this? and
> b) This document is identical to neither 2026 *nor* current procedure,
>so how is it accomplishing the goal of aligning with current
>procedure anyway?

   Although, to tell truth, I don't care very much whether this I-D
becomes an RFC, I am _very_ glad that Pete is raising these questions.

   We have been wandering in the weeds for years now over "how many
steps should there be?" IMHO, the last serious WG effort (newtrk)
reached something very like consensus that that was the wrong question.

   I _seriously_ hope the IESG will either decide to enact this I-D or
stop beating this horse.

   I suggest that we accept the principle that "consensus" process
means it will be hard to change something in the future; and admit
that "adjust to current practice" isn't a sufficient shibboleth to
gain consensus for a change from a previous consensus.

   It _is_ appropriate for anyone sufficiently bothered by failure to
follow current documented rules to appeal actions which don't follow
the "rules". That _will_ make you unpopular with the folks that must
process the appeal, but it is less harmful than asking the entire IETF
to wander in the weeds in seek of consensus to change the "rules".

   If I may make a suggestion, actual practice could be documented on
ietf.org web pages (with some explanation of how it differs from the
RFC "rules" and why) -- without all this wandering in the weeds. It
is _really_ unlikely that would invoke the full appeal process more
than once, and it would save a lot of bandwidth on this list.

   BTW, while I do intend to be silent if the IESG adopts this I-D
for publication, that does _not_ mean I will be silent when the next
"adjust to current practice" I-D comes up.

--
John Leslie 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: What is Native IPv6

[Michel Py]

> JORDI PALET MARTINEZ wrote:
> However, for what it matters here, 6rd is native after
> exiting from the ISP, same as 6to4 is native after
> exiting from the 6to4 relay. As we may not be able to
> know how "much" of the "native" IPv6 traffic is 6rd in
> the last mile, I think we should consider all 6rd traffic
> as native for those measurements, otherwise, we will be
> biasing the data. Even it may be the case of an ISP using
> 6rd for some part of its network, and native for the other.
> We may need to state "IPv6 native as measured, may be
> encapsulated in the last mile".

I disagree.

6RD is not a last mile solution. With the existing levels of IPv6 traffic, an 
ISP would deploy a couple of 6RD relays at their main IX. In a country such as 
France, it means that a 6RD customer in Nice would see their IPv6 traffic being 
encapsulated all the way to Paris over IPv4 crossing the entire ISP's network 
for some 400 miles. In Spain, the really native part of the traffic would 
possibly start in Madrid.

Imagine 2 customers in Barcelona, who are with two different ISPs using 6RD. 
The 6RD relays are in Madrid for both, likely not much more than a few miles 
away or even possibly in the same IX (I don't know the details of IXes in 
Madrid). The 6RD traffic from one goes over IPv4 all the way to Madrid, then 
goes native for a few miles to the other ISP's 6RD relay, then back over IPv4 
to Barcelona. This is not native.

On top of it, like any other tunnel solution, it stinks because the IPv6 
traffic goes back all the way to Madrid while, if it was IPv4, there is a good 
possibility that the two ISPs are peering in Barcelona in a small colo and the 
traffic never leaves the town.

The obvious: the solution is, duh, native IPv6 in Barcelona and the reason ISPs 
are deploying 6RD is, duh, because they don't have it.

As mentioned before by Christian and other, 6RD is very similar to a tunnel 
broker deployment, and the number and location of relays change everything.


> Philip Homburg wrote:
> At the moment, I have 5 IPv6 connections:
> 1) native
> 2) tunnel to my ISP
> 3) tunnel to HE
> 4) tunnel to SixXS
> 5) 6to4
> Obviously, the first one is native and the others aren't,

Then we agree.


> Roger Jørgensen wrote:
> It mean IPv4 running on top of IPv6, IPv6 running on top
> of IPv4 is not native.  But this easy way of seeing it
> only affect IPv4 and IPv6, not all of the others.

I could go for that; native IPv6 mostly means "no IPv4" for the agreed scope. 
But I was trying to be more generic, the idea being to prevent a clever 
marketing droid finding a way to tunnel IPv6 over avian carriers and calling it 
native.

> I guess it all boils down to, are we talking about end
> to end native, or the transportation of the L3 protocol
> being native?

If I understand you correctly (I think I do) I would say it ends up being the 
same thing. What we want is no reliance on IPv4, what we don't want is limit 
implementation options.

How good is a native IPv6 network if it has to be redone when decommissioning 
IPv4? That's where the oxymoron is. I think a good way to see it would be: 
remove all IPv4 end-to-end.  If it still works, it's native IPv6. If not, it's 
not native.

Michel.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Joel M. Halpern]

It seems to me that this does two things, both small but useful.
1) It makes a minor change in the advancement procedures so that they 
are more reasonable.  They may still not be sufficiently reasonable to 
be used, but it improves them, and thereby improves the odds.
2) It is coupled to an intent to actually behave according to what the 
document says.  Such an intent is obviously not feasible without some 
change.  It is useful to have our behavior and our documented 
description of how we work match because the mismatch causes confusion, 
at least for new participants, and sometimes even for experienced 
participants.


It might be the case that it will improve the advancement percentage. 
It might not.  I can not imagine that it will make that even worse.


So, it seems to me that this matches the description that Eric, Brian, 
and others have used of a baby step that is not harmful and may be helpful.


Yours,
Joel

On 7/30/2011 12:55 PM, Pete Resnick wrote:

On 7/28/11 9:03 AM, Eric Burger wrote:


On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote:

1/ I still see no reason to think that this change will cause any
significant change in the percent of Proposed Standards that move up
the
(shorter) standards track since the proposal does nothing to change the
underlying reasons that people do not expend the effort needed to
advance documents


And the real question is, are we moving forward? I think that we are
not moving as far as we originally wanted. However, I offer we are
moving a baby step forward, and as such is worthwhile doing.


On 7/28/11 6:07 PM, Brian E Carpenter wrote:

Let's just make this baby step and stop worrying about it.


Not to pick on Eric and Brian alone; I put this to everyone.

I *really* want an answer to the issue that Scott raises. Eric and Brian
each refer to a "baby step". A baby step toward what exactly?

If the answer is simply, "to align documentation with current
procedure", that's fine, but then I want to know: a) Why is it useful
and positive to line up documentation with current procedure? That is,
what are we gaining by publishing this? and b) This document is
identical to neither 2026 *nor* current procedure, so how is it
accomplishing the goal of aligning with current procedure anyway?

If the answer is, "Yes, this document will cause a change in the percent
of Proposed Standards that move up", then I want to know "How?", because
like Scott, I haven't heard the answer stated in this dicussion.

If you think I've missed an obvious alternative reason to go ahead with
this document, I'm open to hear it, but it sounds like the only two
alternatives expressed so far are, "Document current practice" and
"Improve number of documents moving along standards track", and I
haven't heard how this document does either of those things.

I consider this an open, unaddressed, issue.

pr


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Pete Resnick]

On 7/28/11 9:03 AM, Eric Burger wrote:


On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote:

1/ I still see no reason to think that this change will cause any
significant change in the percent of Proposed Standards that move up the
(shorter) standards track since the proposal does nothing to change the
underlying reasons that people do not expend the effort needed to
advance documents


And the real question is, are we moving forward? I think that we are not moving 
as far as we originally wanted. However, I offer we are moving a baby step 
forward, and as such is worthwhile doing.
   


On 7/28/11 6:07 PM, Brian E Carpenter wrote:

Let's just make this baby step and stop worrying about it.
   


Not to pick on Eric and Brian alone; I put this to everyone.

I *really* want an answer to the issue that Scott raises. Eric and Brian 
each refer to a "baby step". A baby step toward what exactly?


If the answer is simply, "to align documentation with current 
procedure", that's fine, but then I want to know: a) Why is it useful 
and positive to line up documentation with current procedure? That is, 
what are we gaining by publishing this? and b) This document is 
identical to neither 2026 *nor* current procedure, so how is it 
accomplishing the goal of aligning with current procedure anyway?


If the answer is, "Yes, this document will cause a change in the percent 
of Proposed Standards that move up", then I want to know "How?", because 
like Scott, I haven't heard the answer stated in this dicussion.


If you think I've missed an obvious alternative reason to go ahead with 
this document, I'm open to hear it, but it sounds like the only two 
alternatives expressed so far are, "Document current practice" and 
"Improve number of documents moving along standards track", and I 
haven't heard how this document does either of those things.


I consider this an open, unaddressed, issue.

pr

--
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the IESG needs to review everything...

[Dave CROCKER]

Joel, et al,

On 7/28/2011 11:54 PM, Joel M. Halpern wrote:

I think I understand your request taht we move beyond personal anecdotes. In
principle, I even agree with you.

However, when I try to act on that, I am stumped. I do not see any way to
evaluate say the last 2 years discusses to determine whether they were more
harmful or more helpful.


1. Pursue serious discussions that consider criteria for determining that.  A 
variety of obvious candidates for this list come to mind readily; for example:


   *  Does a review of the Discuss now produce a sense of its worth?  That is, 
do the rest of us, looking at the Discuss generally feel that it was clear and 
substantive and even important?


   *  Does the Discuss obviously align with the criteria for a Discuss?

   *  Does the AD who held the Discuss now feel that it was productive, and why?

   *  Do the authors and chairs now feel that it was productive, and why?

   *  How much delay did the Discuss introduce?  Was it timely?

   *  How much effort did it take to resolve the discuss?

   *  Did the Discuss produce a change in normative text?

   *  Does a review of the change in text, now, produce a sense of its worth?
   ...

It could well be worth trying to classify typical types of Discusses, such as:

   *  Curiosity questions.  "I'd like to understand..." where no actual problem 
is cited


   *  Review enforcement.  Ensuring that particular points from other reviews 
are resolved


   *  Personal preference.  AD dislike of a working group choice, without a 
clear basis the makes clear why the wg choice won't work or is otherwise impractical


   *  Fundamental problem.  Assertion of a basic limitation to the 
specification that renders it inherently problematic


   *  Scope.  The Discuss appears to be out of scope for the document.  For 
example, a document intended for Draft is being challenged on basic issues that 
were approved when it went to Proposed.


   *  Unclear.  The meaning of the Discuss is unclear and/or the path towards 
resolution cannot be understood because the Discuss offers no clear criteria for 
resolution.


  To illustrate this last item with examples that almost certainly have 
never happened:


  o  If a Discuss said "needs to be written in an active voice rather than 
passive", it would be clear what would resolve it.


  o  If a Discuss said "needs to be shorter", there's a clear direction for 
resolution, but no criteria for for knowing when it is short enough.


  o  If a Discuss said "Algorithm X in the specification will not work for 
the following reasons...; Algorithm Y is better for the following reasons" then 
it is clear what the problem is, why it is a problem and exactly what will 
satisfy the AD to resolve it.


   ...

It can also be worth looking at meta-issues.  For example, do documents 
typically get a Discuss?  That is, is it typical to block progress for a 
document?  Does it make sense to have working groups proceed for many months and 
then have presumably basic issues raised at the very last moment?



2. Review the datatracker histories over the last  years, sampling enough of 
the documents to get a sense of the overall pattern.  (The new datatracker now 
supports provides a complete history for the handling of drafts; massive kudos 
to the tools team!)



3. Talk with authors, chairs and ADs about previous Discusses.



But you asked that we go beyond that. How?


The above is meant to prime a serious discussion, but the first requirement is a 
willingness to engage in that discussion and to pursue it seriously.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DKIM Signatures now being applied to IETF Email

[Hector Santos]

Dave CROCKER wrote:

It does seem odd to complain about a mechanism that (finally) provides a 
certifiably valid identifier on messages, in an environment where 90% of 
the traffic across the Internet exploits the fact that there hasn't been 
one...


How it is certified?  I haven't seen any DKIM message that comes with 
a certified identifier. Is there consistency in the certification 
across all DKIM verifiers? What do you when it isn't certified which 
is 99% of the DKIM signed mail coming in?   And how does one leverage 
or mitigate this 90% asserted exploitation with DKIM?  Should we begin 
to reject mail that do not have valid signatures?


Without a domain policy based security wrapper, DKIM remains an 
unsecured protocol and currently it is just wasted processing 
bandwidth with a huge cost in implementation and management, or just 
plain old getting it right, and even then, most people in our market 
don't understand what utility it offers them.  At present, they 
believe the "new badge" will help them look better, but there is no 
real evidence that it does anything for them.


--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: What is Native IPv6

[Philip Homburg]

In your letter dated Fri, 29 Jul 2011 19:31:13 -0700 you wrote:
>- If one is in the business of writing an draft about "what is native
>IPv6", and if one of the draft's goals is to reach -cough- consensus
>-cough-, one may consider "forgetting" the 6PE classification
>altogether. The one part that is not open for grabs with me is
>classifying 6RD as native.

Why do you care so much about 'native'?

At the moment, I have 5 IPv6 connections:
1) native
2) tunnel to my ISP
3) tunnel to HE
4) tunnel to SixXS
5) 6to4

Obviously, the first one is native and the others aren't, But as user of those
links, it seems a completely arbitrary and useless distinction.
Number 5, 6to4 is obviously a problem. So that's in the 'avoid' category.
Number 3 and 4, require good access to the IPv4 Internet. At the moment
they work perfectly, but they are not future proof.
Numbers 1 and 2. In first case, ppp frames go over atm/ethernet to my ISP.
In the second case, IPv4 packets go over ppp frames over atm/ethernet to my
ISP. Yes, compared to native, the tunnel has an extra IPv4 header, but
otherwise, there is no difference. (At my ISP, native and tunneled are
terminated differently, but so far that difference is almost impossible to
notice)

So my classification would be
1) IPv6 provided by the user's ISP. (native, 6rd, tunnel by ISP)
2) IPv6 provided by a third party (tunnels by other parties)
3) IPv6 provided by unknown third parties (6to4, teredo)

1) can be made to work very well, 2) has problems, 3) is to be avoided.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: What is Native IPv6

[Keith Moore]

On Jul 30, 2011, at 10:45 AM, JORDI PALET MARTINEZ wrote:

> However, for what it matters here, 6rd is native after exiting from the
> ISP, same as 6to4 is native after exiting from the 6to4 relay.
> 
> As we may not be able to know how "much" of the "native" IPv6 traffic is
> 6rd in the last mile, I think we should consider all 6rd traffic as native
> for those measurements, otherwise, we will be biasing the data. Even it
> may be the case of an ISP using 6rd for some part of its network, and
> native for the other.

good points.

I suspect that what many people are interested in is not whether the v6 traffic 
is "native" end-to-end, but rather, something like:

a) How much of this traffic is _managed_ end-to-end vs. how much relies on 
ad-hoc "kindness of strangers" e.g. RFC 3068 which we know is less reliable.
b) If certain transition mechanisms happen to be very effective/useful at 
getting people onto IPv6 (or not), which ones are those?  

Of course, some of these things are easier to measure than others.

Then again, others really are interested in whether the traffic is "native", 
since perhaps they care about applications (media streaming?) that are 
significantly impacted by tunneling.

Keith


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DKIM Signatures now being applied to IETF Email

[Dave CROCKER]

On 7/30/2011 6:26 AM, t.petch wrote:

Sadly, I do not see it being used in the mailing lists where an
organisation is sending me directly data I would like to be able to rely on
- which I think fits the applicability well - and instead, I see it
being used on a mailing list such as those in the IETF where I
believe that the costs outweigh the benefits - and I have no choice
about that:-(.



Costs?

1. The only place that DKIM information appears in a message is in a special 
header-field.


2. If your system does not process DKIM and you don't display the full header, 
you don't even see that it is there; unlike OpenPGP and S/MIME, there is no 
evidence of DKIM in the body.


3. The increase in size in message size is felt by the industry to be a minor 
"cost", especially given all the other functions that already increase message size.


4. If the extra bytes are such a terrible burden for you, strip the field off.

It does seem odd to complain about a mechanism that (finally) provides a 
certifiably valid identifier on messages, in an environment where 90% of the 
traffic across the Internet exploits the fact that there hasn't been one...


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DKIM Signatures now being applied to IETF Email

[t.petch]

- Original Message -
From: "Barry Leiba" 
To: "t.petch" 
Cc: "ietf" 
Sent: Friday, July 29, 2011 5:02 PM

> I think that it is an error for the IETF to add DKIM signatures. They do
indeed
> tell me
> which intermediary has sent me the mail, but does nothing for the 'spam' that
> the
> intermediary accepted in the first place (albeit there being little of that on
> the IETF
> managed lists).
...
> It functions, but does not work, in that it tells me nothing about the true
> origin of the communication.

What it does is allow you to assure yourself that the message was,
indeed, from an IETF mailing list (well, from an IETF email server),
and that it wasn't that someone tried to spoof that.  That, in turn,
allows you to confidently increase your trust that the message is not
spam in proportion to your confidence in the IETF's spam-filtering
capabilities.

Some of us, at least, find that useful.  Some of us might even
completely white-list IETF-signed messages.  You can make your own
choice on that.


Yes, I do understand that - having read the first round of DKIM RFC
when they came out all those years ago - and do see it as a useful
tool for improving the security of e-mail and I should have made
that clearer in my first e-mail.

Sadly, I do not see it being used in the mailing lists where an
organisation is sending me directly data I would like to be able to rely on
- which I think fits the applicability well - and instead, I see it
being used on a mailing list such as those in the IETF where I
believe that the costs outweigh the benefits - and I have no choice
about that:-(.

Tom Petch

Barry, DKIM WG chair

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: What is Native IPv6

[Roger Jørgensen]

On Sat, Jul 30, 2011 at 4:31 AM, Michel Py
 wrote:
> Ole,
>> Ole Troan wrote:
>> I presume you are arguing that MPLS (6PE) is not native either?
> That's a tough one.
>
> What would make me say it is native is: MPLS is a L2/switching animal,
> not a L3/routing one. In theory you can bind any L3 protocol such as
> IPv4, IPv6, IPX, Appletalk, etc to it. So the MPLS interface is very
> similar in some aspects to a real physical interface such as Ethernet or
> HSSI. It reminds me of a frame-relay sub-interface in a past life.
>
> What would make me say it is not native is: you can't remove IPv4 out of
> the equation. Frame relay does not even know about which L3 protocols it
> transports, while MPLS is kinda going the reverse way in the stack: it
> uses L3 packets/datagrams to encapsulate and transport "L2 frames".
>
> Here's my take:
> - You can have native IPv6 over Ethernet or HDLC or Sonet or any other
> L2 technology.
>
> - Saying you have native IPv6 over fiber or copper is incorrect; you
> have native IPv6 over GigE over {singlemode|multimode} (*) fiber or you
> have IPv6 over Ethernet over GigE over (*) copper (or other examples)
> (*) insert the appropriate 802.x standard
>
> - I like the idea of being native requiring the IPv6 to be bound to a L2
> interface. The gray area with 6PE is that the interface is logical, not
> physical.
>
> - Native IPv6 over a 6to4 or a 6RD or any kind of L3-L3 tunnel is an
> oxymoron.
>
>
>
> In other words: native IPv6 means:
> a) IPv6 has to be bound to a L2 interface.
> b) That interface can NOT be a tunnel interface using another L3
> protocol such as IPv4.
>
> Up for grabs:
>
> - c1) Is it acceptable to have a structural requirement to use IPv4
> (which would mean 6PE is native) or c2) is it a requirement that the
> entire infrastructure (in the case of 6RD, the ISP's infrastructure)
> supports IPv6 (which would mean that 6PE is not native).
>
> Food for thought:
>
> - If c2) is chosen, I would consider rephrasing a) so it becomes "IPv6
> has to be bound to a PHYSICAL L2 interface". Rationale: besides 6PE, are
> there any other gray area candidates?
>
> - If one is in the business of writing an draft about "what is native
> IPv6", and if one of the draft's goals is to reach -cough- consensus
> -cough-, one may consider "forgetting" the 6PE classification
> altogether. The one part that is not open for grabs with me is
> classifying 6RD as native.

let me try to write all of the above in my own wording to see if I
understand what you mean...

Anything doing translation L3 <> L3 is not native, that's an easy one.
It mean IPv4 running on top of IPv6, IPv6 running on top of IPv4 is
not native.  But this easy way of seeing it only affect IPv4 and IPv6,
not all of the others.

As you said somewhere in there, anything attached to a L2 interface is
L3 and in that respect native as long as the transport from that L2
interface do not require other L3 protocols to work?
(of course it gets hairy when you involve MPLS according to Michel's
text above)



When Jordi says:
"However, for what it matters here, 6rd is native after exiting from the
ISP, same as 6to4 is native after exiting from the 6to4 relay."

That fails the first one, it is _translated_ on L3 and is because of
that not native, even if the transportation of the packet after the
translation is 100% native as in not require another L3 protocol to
work.



I guess it all boils down to, are we talking about end to end native,
or the transportation of the L3 protocol being native?

-- 

Roger Jorgensen           |
rog...@gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | ro...@jorgensen.no
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: What is Native IPv6

[JORDI PALET MARTINEZ]

However, for what it matters here, 6rd is native after exiting from the
ISP, same as 6to4 is native after exiting from the 6to4 relay.

As we may not be able to know how "much" of the "native" IPv6 traffic is
6rd in the last mile, I think we should consider all 6rd traffic as native
for those measurements, otherwise, we will be biasing the data. Even it
may be the case of an ISP using 6rd for some part of its network, and
native for the other.

We may need to state "IPv6 native as measured, may be encapsulated in the
last mile".

Regards,
Jordi






-Mensaje original-
De: Michel Py 
Responder a: 
Fecha: Fri, 29 Jul 2011 19:31:13 -0700
Para: Ole Troan 
CC: Tim Chown , IETF Discussion 
Asunto: What is Native IPv6

>Ole,
>
>> Ole Troan wrote:
>> I presume you are arguing that MPLS (6PE) is not native either?
>
>That's a tough one.
>
>What would make me say it is native is: MPLS is a L2/switching animal,
>not a L3/routing one. In theory you can bind any L3 protocol such as
>IPv4, IPv6, IPX, Appletalk, etc to it. So the MPLS interface is very
>similar in some aspects to a real physical interface such as Ethernet or
>HSSI. It reminds me of a frame-relay sub-interface in a past life.
>
>What would make me say it is not native is: you can't remove IPv4 out of
>the equation. Frame relay does not even know about which L3 protocols it
>transports, while MPLS is kinda going the reverse way in the stack: it
>uses L3 packets/datagrams to encapsulate and transport "L2 frames".
>
>
>Here's my take:
>- You can have native IPv6 over Ethernet or HDLC or Sonet or any other
>L2 technology.
>
>- Saying you have native IPv6 over fiber or copper is incorrect; you
>have native IPv6 over GigE over {singlemode|multimode} (*) fiber or you
>have IPv6 over Ethernet over GigE over (*) copper (or other examples)
>(*) insert the appropriate 802.x standard
>
>- I like the idea of being native requiring the IPv6 to be bound to a L2
>interface. The gray area with 6PE is that the interface is logical, not
>physical.
>
>- Native IPv6 over a 6to4 or a 6RD or any kind of L3-L3 tunnel is an
>oxymoron.
>
>
>
>In other words: native IPv6 means:
>a) IPv6 has to be bound to a L2 interface.
>b) That interface can NOT be a tunnel interface using another L3
>protocol such as IPv4.
>
>Up for grabs:
>
>- c1) Is it acceptable to have a structural requirement to use IPv4
>(which would mean 6PE is native) or c2) is it a requirement that the
>entire infrastructure (in the case of 6RD, the ISP's infrastructure)
>supports IPv6 (which would mean that 6PE is not native).
>
>Food for thought: 
>
>- If c2) is chosen, I would consider rephrasing a) so it becomes "IPv6
>has to be bound to a PHYSICAL L2 interface". Rationale: besides 6PE, are
>there any other gray area candidates?
>
>- If one is in the business of writing an draft about "what is native
>IPv6", and if one of the draft's goals is to reach -cough- consensus
>-cough-, one may consider "forgetting" the 6PE classification
>altogether. The one part that is not open for grabs with me is
>classifying 6RD as native.
>
>
>Michel.
>
>___
>Ietf mailing list
>Ietf@ietf.org
>https://www.ietf.org/mailman/listinfo/ietf



**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf