Campaign for Dictatorship is at an End

It's over.  You won't have Mitchell to kick around any more, because,
gentlemen, this is my last press conference -- whoops, I mean, my last
April Fools' Day letter regarding my campaign to become Benevolent
Internet Dictator.  Just think how much you're going to be missing.
If my campaign had succeeded, I would have mandated universal use of
IPv6, and banned base64 encoded plain text and top posting.

Although my quixotic campaign is over, my site at
http://www.f-iw.org/random.cgi is still generating random numbers which
I personally guarantee to be hexadecimal.  Happy April 1!

George Mitchell

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Weekly posting summary for ipv6 <at> ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 20.00% |    1 | 24.72% |     5293 | rfc-editor <at> rfc-editor.org
 20.00% |    1 | 22.61% |     4842 | mailer-daemon <at> ktf.com
 20.00% |    1 | 18.20% |     3896 | sra+ipng <at> hactrn.net
 20.00% |    1 | 18.14% |     3885 | mailman-owner <at> ietf.org
 20.00% |    1 | 16.32% |     3495 | george+ipng <at> m5p.com
--------+------+--------+----------+------------------------
100.00% |    5 |100.00% |    21411 | Total

Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the IPv6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

ND on point-to-point links

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[ND on point-to-point links]RE: ipv6 Digest, Vol 24, Issue 2

I think it is not mandatory to implement ND on p2p links or it is not
mandatory to do Address Resolution on p2p links, but should implement
DAD on p2p links. To the PPPoE scenario, I think should not implement
Address Resolution on virtual PPP links.

-----Original Message-----
From: ipv6-request <at> ietf.org [mailto:ipv6-request <at> ietf.org] 
Sent: Tuesday, April 04, 2006 12:00 AM
To: ipv6 <at> ietf.org
Subject: ipv6 Digest, Vol 24, Issue 2

Send ipv6 mailing list submissions to
	ipv6 <at> ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/ipv6
or, via email, send a message with subject or body 'help' to
	ipv6-request <at> ietf.org

You can reach the person managing the list at
	ipv6-owner <at> ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ipv6 digest..."

Today's Topics:

   1. ND on point-to-point links (Yu-Jung Lee)

----------------------------------------------------------------------

Message: 1
Date: Mon, 3 Apr 2006 15:05:31 +0800
From: "Yu-Jung Lee" <yjlee <at> zyxel.com.tw>
Subject: ND on point-to-point links
To: <ipv6 <at> ietf.org>
Message-ID: <006d01c656ec$fea1e050$471517ac <at> 1194201>
Content-Type: text/plain; charset="big5"

Hi,

According to RFC 2461, there's a description about ND on point-to-point
links: 

     point-to-point - Neighbor Discovery handles such links just like
                      multicast links.  (Multicast can be trivially
                      provided on point to point links, and interfaces
                      can be assigned link-local addresses.)  Neighbor
                      Discovery should be implemented as described in
                      this document.

The saying is not explicit enough. Does it mean it's not mandatory to
implement ND on p2p links? If it's not a MUST, what is a node supposed
to do when it receives a NS? Currently, we test against Juniper's router
with p2p link (including PPPoE, PPPoA, and RFC 1483 Route). Our device
sends out NS, but the peer does not send a NA message in response, which
causes some interoperability issues. Besides, on a p2p link, is it
mandatory for a router to send out RA?

Best Regards,

Jessie
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www1.ietf.org/pipermail/ipv6/attachments/20060403/28ca5860/attach
ment.html

------------------------------

_______________________________________________
ipv6 mailing list
ipv6 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipv6

End of ipv6 Digest, Vol 24, Issue 2
***********************************


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Ethernet as a shared (not broadcast) network?

In perusing old RFCs, I think I've come across a rather odd possibility that 
doesn't seem to be explicitly prohibited but is probably accidental: using 
multiple Ethernets operating as a single "shared" network instead of as 
multiple "broadcast" networks, to use RFC 2461 section 2.2 terms.

To understand the possible use of this, consider a site where there are 
multiple Ethernet VLANs in use, perhaps dozens, but the administrator wishes 
to use a single /64 for all of them without bridging them together.  This is 
conceptually similar to OSI's concept of "area" addressing.

Obviously, the routers would need to allow assigning the same prefix to 
multiple interfaces, and the L bit in the ICMPv6 RA's Prefix Information 
option would need to be clear (0).  When L=0, all hosts on any of the VLANs 
would forward packets to new destinations to a router.  If the destination 
were on the same VLAN the router would send a Redirect message; if not, the 
packet would be forwarded as normal.  This looks fairly useful in some 
scenarios.

A few obvious problems come to mind:

1. Any router connected to one VLAN in the "area" must be connected to all 
such VLANs.  If not, routing protocol modifications would be required so 
that routers would be able to forward to destinations not on an attached 
link.
2. Multicast semantics are not obvious.  Should a multicast packet of link 
scope be forwarded to the other VLANs?  ICMP RA/RS/ND gets ugly if you do 
that.  I think multicast packets of greater scope will work correctly, but I 
get lost in all the corner cases.
3. Hosts may not expect L=0 on Ethernets and behave incorrectly.

Solutions?  Other problems?  Doubts about my mental health?

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Re: Ethernet as a shared (not broadcast) network?

Let me ask: would this be any different than putting an Ethernet  
switch in front of a router port?

I believe that there will be a market for this in the home.

On Apr 4, 2006, at 3:30 PM, Stephen Sprunk wrote:

> In perusing old RFCs, I think I've come across a rather odd  
> possibility that doesn't seem to be explicitly prohibited but is  
> probably accidental: using multiple Ethernets operating as a single  
> "shared" network instead of as multiple "broadcast" networks, to  
> use RFC 2461 section 2.2 terms.
>
> To understand the possible use of this, consider a site where there  
> are multiple Ethernet VLANs in use, perhaps dozens, but the  
> administrator wishes to use a single /64 for all of them without  
> bridging them together.  This is conceptually similar to OSI's  
> concept of "area" addressing.
>
> Obviously, the routers would need to allow assigning the same  
> prefix to multiple interfaces, and the L bit in the ICMPv6 RA's  
> Prefix Information option would need to be clear (0).  When L=0,  
> all hosts on any of the VLANs would forward packets to new  
> destinations to a router.  If the destination were on the same VLAN  
> the router would send a Redirect message; if not, the packet would  
> be forwarded as normal.  This looks fairly useful in some scenarios.
>
> A few obvious problems come to mind:
>
> 1. Any router connected to one VLAN in the "area" must be connected  
> to all such VLANs.  If not, routing protocol modifications would be  
> required so that routers would be able to forward to destinations  
> not on an attached link.
> 2. Multicast semantics are not obvious.  Should a multicast packet  
> of link scope be forwarded to the other VLANs?  ICMP RA/RS/ND gets  
> ugly if you do that.  I think multicast packets of greater scope  
> will work correctly, but I get lost in all the corner cases.
> 3. Hosts may not expect L=0 on Ethernets and behave incorrectly.
>
> Solutions?  Other problems?  Doubts about my mental health?
>
> S
>
> Stephen Sprunk        "Stupid people surround themselves with smart
> CCIE #3723           people.  Smart people surround themselves with
> K5SSS         smart people who disagree with them."  --Aaron Sorkin
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 <at> ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Re: Ethernet as a shared (not broadcast) network?

Stephen,

I think you have reinvented what has been called multilink subnets.   
This has been discussed at some length in the IPv6 working group and  
the conclusion was to not go there in the general case.  We did  
produce a very simple version called "ND Proxy".  See: http:// 
www.ietf.org/internet-drafts/draft-ietf-ipv6-ndproxy-04.txt.  This is  
currently in RFC-Editor queue.

Dave Thaler also wrote a draft on the general topic that was  
presented at the internet area meeting in Dallas:

   Issues With Protocols Proposing Multilink Subnets

   http://www.ietf.org/internet-drafts/draft-thaler-intarea-multilink- 
subnet-issues-00.txt

Bob

On Apr 4, 2006, at 3:30 PM, ext Stephen Sprunk wrote:

> In perusing old RFCs, I think I've come across a rather odd  
> possibility that doesn't seem to be explicitly prohibited but is  
> probably accidental: using multiple Ethernets operating as a single  
> "shared" network instead of as multiple "broadcast" networks, to  
> use RFC 2461 section 2.2 terms.
>
> To understand the possible use of this, consider a site where there  
> are multiple Ethernet VLANs in use, perhaps dozens, but the  
> administrator wishes to use a single /64 for all of them without  
> bridging them together.  This is conceptually similar to OSI's  
> concept of "area" addressing.
>
> Obviously, the routers would need to allow assigning the same  
> prefix to multiple interfaces, and the L bit in the ICMPv6 RA's  
> Prefix Information option would need to be clear (0).  When L=0,  
> all hosts on any of the VLANs would forward packets to new  
> destinations to a router.  If the destination were on the same VLAN  
> the router would send a Redirect message; if not, the packet would  
> be forwarded as normal.  This looks fairly useful in some scenarios.
>
> A few obvious problems come to mind:
>
> 1. Any router connected to one VLAN in the "area" must be connected  
> to all such VLANs.  If not, routing protocol modifications would be  
> required so that routers would be able to forward to destinations  
> not on an attached link.
> 2. Multicast semantics are not obvious.  Should a multicast packet  
> of link scope be forwarded to the other VLANs?  ICMP RA/RS/ND gets  
> ugly if you do that.  I think multicast packets of greater scope  
> will work correctly, but I get lost in all the corner cases.
> 3. Hosts may not expect L=0 on Ethernets and behave incorrectly.
>
> Solutions?  Other problems?  Doubts about my mental health?
>
> S
>
> Stephen Sprunk        "Stupid people surround themselves with smart
> CCIE #3723           people.  Smart people surround themselves with
> K5SSS         smart people who disagree with them."  --Aaron Sorkin
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 <at> ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

FW: I-D ACTION:draft-wen-ipv6-rsra-opt-pid-00.txt

Dear all,

Here is a draft which makes SAAC possible without upgrading access node and CPE to be layer3 devices.
Hope you could comment on it. Thank you.

Best regards,

Haibo

-----Original Message-----
From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org]
Sent: 2006年4月5日 03:50
To: i-d-announce <at> ietf.org
Subject: I-D ACTION:draft-wen-ipv6-rsra-opt-pid-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Port Identifier option for RS/RA messages in IPv6 access network
	Author(s)	: H. Wen
	Filename	: draft-wen-ipv6-rsra-opt-pid-00.txt
	Pages		: 11
	Date		: 2006-4-4
	
This document makes an extension to stateless address auto-
configuration (SAAC) mechanism by defining Port Identifier option for
RS/RA messages in IPv6 access network. This option can make SAAC 
possible without upgrading access node and CPE to be layer 3 devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wen-ipv6-rsra-opt-pid-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-wen-ipv6-rsra-opt-pid-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-wen-ipv6-rsra-opt-pid-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

FW: I-D ACTION:draft-wen-ipv6-rsra-opt-multihoming-00.txt

Dear all,

I propose a draft which uses RS/RA to help implement multi-homing issue.
Hope all experts could comment on it. Thank you in advance.

Best regards,

Haibo

-----Original Message-----
From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org]
Sent: 2006年4月5日 03:50
To: i-d-announce <at> ietf.org
Subject: I-D ACTION:draft-wen-ipv6-rsra-opt-multihoming-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Multi-homing Information option for Stateless Address Auto-Configuration
	Author(s)	: H. Wen
	Filename	: draft-wen-ipv6-rsra-opt-multihoming-00.txt
	Pages		: 14
	Date		: 2006-4-4
	
   This document makes an extension to the standard RS/RA messages for
   IPv6 network to solve some problems occurring in multi-homing
   evironment. A new options, that is, Multi-homing Information option 
   is defined to help host do network selection and prefix selection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wen-ipv6-rsra-opt-multihoming-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-wen-ipv6-rsra-opt-multihoming-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-wen-ipv6-rsra-opt-multihoming-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Re: Ethernet as a shared (not broadcast) network?

Thus spake "Bob Hinden" <bob.hinden <at> nokia.com>
> I think you have reinvented what has been called multilink subnets.   This 
> has been discussed at some length in the IPv6 working group and  the 
> conclusion was to not go there in the general case.  We did  produce a 
> very simple version called "ND Proxy".  See: http:// 
> www.ietf.org/internet-drafts/draft-ietf-ipv6-ndproxy-04.txt.  This is 
> currently in RFC-Editor queue.

Interesting, but it's sufficiently different from what I envisioned I didn't 
see a connection.  It shows me the value of creating specific protocols to 
cover a specific set of use cases, though, rather than one that tries to 
cover them all.

> Dave Thaler also wrote a draft on the general topic that was  presented at 
> the internet area meeting in Dallas:
>
>   Issues With Protocols Proposing Multilink Subnets
>
>   http://www.ietf.org/internet-drafts/draft-thaler-intarea-multilink- 
> subnet-issues-00.txt

Very good reading; thanks for the pointer.

It seems the main issue is multicast propogation, which is one I'd come up 
with but didn't see the full ramifications of.  In fact, limiting 
multicast/broadcast traffic is one of my main reasons for wanting multilink 
subnets (the other being STP scaling problems).  I'll have to think about 
if/how the listed problems apply to what I had in mind; they might be 
considered features in some environments, not bugs.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------