Ruri Hiromi | 11 Jan 2007 04:21
Favicon

Re: I-D ACTION:draft-ietf-v6ops-addr-select-req-00.txt

Brian,

excuse my late responding to this, but may I clarify your comment?

Now we can't think of how to set preference for ISPs because the  
RFC3484(or its update) solve this, but does it suggests we should  
consider additional section about network topologies with how to  
operate multiple policies?

Or does it mean simply adding definition of xSP?  If yes, I will add  
like this.
(Addition into Section 2 at Terminology.)
xSP: a service provider who is an owner of the address prefix(es). It  
inputs the address prefix to the Policy Broker.

Regards,

On 2006/11/25, at 1:13, Brian E Carpenter wrote:

> It seems to me that in addition to mentioning an xSP as the
> source of address selection, a corporate or campus network
> operator should also be mentioned*. I'm especially thinking
> of a corporate network with many points of connection to
> several ISPs; that can make the policy quite complex
> and location dependent.
>
> I don't think this will change the actual technical
> requirements much, but it needs to be considered.
>
>     Brian
(Continue reading)

Fred Baker | 11 Jan 2007 09:09
Picon
Favicon

draft-ietf-v6ops-scanning-implications WGLC

This is to announce a working group last call of http:// 
tools.ietf.org/html/draft-ietf-v6ops-scanning-implications. It has  
had review in DHCP and the DNS Extensions Working Groups, and we need  
now to come to closure on it.

Please read the draft at this time, noting spelling or wording issues  
to the authors and substantive issues to the authors copying the list.

Working Group last call will close in two weeks.

Arifumi Matsumoto | 11 Jan 2007 10:49

Re: about draft-ietf-v6ops-addr-select-req-00.txt

Hi.

Let me re-post my e-mail below as I haven't received any feedbacks.
I'll include these discussions in the next revision and post it soon.

Regards.

Arifumi Matsumoto wrote:
> Hi all,
> I'm sorry for my late action for this new wg draft.
> 
> I listed some points that was raised at San Diego and my comments below.
> Let me classify these into 3 classes from the aspect of RFC3484 revision.
> To move forward requirements draft, I suppose it's better to decide
> what the base mechanism is we can rely on. That is, we can assume RFC3484
> as it is now, or modified RFC3484 or nothing (start from zero).
> 
> 1) Issues that don't need RFC3484 modification.
>  - specific set of policies to a specific host.
>    This issue is already in the requiremnt draft.
> 
> 2) Issues that may need slight RFC3484 change.
>  - The address type dependent preference.
>    There was a thread "address selection and DHCPv6" by James Carlson
>    at IPv6 ML about address type dependent preference, such as DHCPv6,
>    RA, manual and also privacy extension(RFC3041) address.
>    http://www1.ietf.org/mail-archive/web/ipv6/current/msg06910.html
> 
>    It is hard to define default preferences for these address types,
>    because IMO it depends on the usage of these addresses, but not on
(Continue reading)

Brian E Carpenter | 11 Jan 2007 10:45
Picon
Favicon

Re: I-D ACTION:draft-ietf-v6ops-addr-select-req-00.txt

A definition is all I want, but you still do not state whether
it includes a campus or enterprise network, which I think will
confuse people who are used to SP = ISP.

     Brian

On 2007-01-11 04:21, Ruri Hiromi wrote:
> Brian,
> 
> excuse my late responding to this, but may I clarify your comment?
> 
> Now we can't think of how to set preference for ISPs because the 
> RFC3484(or its update) solve this, but does it suggests we should 
> consider additional section about network topologies with how to operate 
> multiple policies?
> 
> Or does it mean simply adding definition of xSP?  If yes, I will add 
> like this.
> (Addition into Section 2 at Terminology.)
> xSP: a service provider who is an owner of the address prefix(es). It 
> inputs the address prefix to the Policy Broker.
> 
> Regards,
> 
> On 2006/11/25, at 1:13, Brian E Carpenter wrote:
> 
>> It seems to me that in addition to mentioning an xSP as the
>> source of address selection, a corporate or campus network
>> operator should also be mentioned*. I'm especially thinking
>> of a corporate network with many points of connection to
(Continue reading)

Andrew Sullivan | 11 Jan 2007 15:32

Re: draft-ietf-v6ops-scanning-implications WGLC

Hello,

On Thu, Jan 11, 2007 at 09:09:12AM +0100, Fred Baker wrote:
> Please read the draft at this time, noting spelling or wording issues  
> to the authors and substantive issues to the authors copying the list.

I have read the draft.  I have a small concern about a sentence in
section 3.4:

   It is also worth noting that the reverse DNS tree may also expose
   address information.

The way the section is worded, it sounds as though the draft is
recommending not to publish data in the reverse tree in order to
avoid this vector for attack.  If the paragraph were altered to read
as follows, the implication would not be there, I think:

   It is also worth noting that the reverse DNS tree may also expose
   address information.  Populating the reverse DNS tree for the
   entire subnet, even if not all addresses are actually used, may
   reduce that exposure.

Best regards,
Andrew Sullivan

--

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew@...>                              M2P 2A8
(Continue reading)

Internet-Drafts | 11 Jan 2007 21:50
Picon
Favicon

I-D ACTION:draft-ietf-v6ops-nap-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: Local Network Protection for IPv6
	Author(s)	: G. Van de Velde, et al.
	Filename	: draft-ietf-v6ops-nap-06.txt
	Pages		: 46
	Date		: 2007-1-11
	
Although there are many perceived benefits to Network Address
   Translation (NAT), its primary benefit of "amplifying" available
   address space is not needed in IPv6.  In addition to NAT's many
   serious disadvantages, there is a perception that other benefits
   exist, such as a variety of management and security attributes that
   could be useful for an Internet Protocol site.  IPv6 was designed
   with the intention of making NAT unnecessary, and this document shows
   how Local Network Protection (LNP) using IPv6 can provide the same or
   more benefits without the need for address translation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-06.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 
(Continue reading)

Pars Mutaf | 12 Jan 2007 15:25
Picon

Re: [16NG] Re: multicast and IPv6 over ETHCS

Hi, sorry for popping up,

On Fri, 2007-01-12 at 12:19 +0100, Alexandru Petrescu wrote:
> Hi Jihoon, thanks for reply,
> 
> Jihoon Lee wrote:
> > Hi Alex,
> > 
> > Let me jump into discussion. 1) 802.16/16e MAC has no capability to 
> > do uplink multicast. In DL, 802.16 provides multicast CIDs which is 
> > initiated by DSA messages. In UL, however, there is no way for an MS 
> > to access others' UL data fundamentally, in 802.16 PHY/MAC.

Do you think this is an accidental design choice (i.e. no uplink
multicast)? Or 802.16/16e MAC designers had very good fundamental
reasons? 

(I'm sorry. This question looks out-of IETF scope. But I think we may 
learn something more general i.e. useful to IP perhaps?)

Thank you.
pars

> Ok.  For one, if the 802.16MAC is not capable to do bidirectional (or
> normal) multicast then that is a big issue for IPv6-over-IPv6CS. (and
> surprisingly, apparently the document IPv6-over-IPv6CS doesn't seem to
> mention the word 'multicast'.)

> 
> The issue is that a SS running IPv6 needs to multicast a NA, from time
(Continue reading)

Qiang Zhang | 14 Jan 2007 05:56
Picon

Re: [16NG] Re: multicast and IPv6 over ETHCS


Hi All,

Physical layer UL/DL multicast or multiPackets should not be confused with the access network multicast which can go across multiple cells managed by one ASN, I think there should be no restriction for the design to incorporate the IP or Eth level multicast initiated from  the ASN after receiving a IP multicast packet from the MS, am confused why can't the ASN also broadcast/multicast back to the same cell the MS is residing if you can clarify

Qiang

On 1/13/07, Jihoon Lee <jhlee-hgMlF/s9d4Qva5B95RgorA@public.gmane.org> wrote:
Hi Alex,
 
Sorry for my late response. Basically I agree with your opinion.
An IPv6 node requires a link local multicast address in order to perform DAD, ND, and RA.
 
Contrary to our expectations, 802.16/16e don't support UL multicast (which means an MS forwards data directly to other MSs in the same cell).
 
(BTW, I think I need to clarify the UL multicast I mentioned. I believe you already know this: the multicast/broadcast which is sent by an MS  to other MSs in the same cell (BS) cannot be supported in 802.16. However, other MSs in another cell (BS) may receive this since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at ETH or IP layer.)   
 
I agree that the document needs to specify how to deal with this problem. 
 
Best regards,
Jihoon

 
2007/1/12, Alexandru Petrescu <alexandru.petrescu-3WKxDLwmzFNWk0Htik3J/w@public.gmane.org >:
Hi Jihoon, thanks for reply,

Jihoon Lee wrote:
> Hi Alex,
>
> Let me jump into discussion. 1) 802.16/16e MAC has no capability to
> do uplink multicast. In DL, 802.16 provides multicast CIDs which is
> initiated by DSA messages. In UL, however, there is no way for an MS
> to access others' UL data fundamentally, in 802.16 PHY/MAC.

Ok.  For one, if the 802.16MAC is not capable to do bidirectional (or
normal) multicast then that is a big issue for IPv6-over-IPv6CS. (and
surprisingly, apparently the document IPv6-over-IPv6CS doesn't seem to
mention the word 'multicast'.)

The issue is that a SS running IPv6 needs to multicast a NA, from time
to time.  For DAD it needs to send a NS to a multicast address too.

> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS
> sends multicast data in UL, and then a bridge forwards it back). But,
>  there is still a difficulty in multicasting data back except for the
>  source MS.

You mean the bridge in BS?  I was thinking ETHCS in SS may offer a
multicast interface to the IP stack.

In both cases (bridge in BS or bridge in SS), I think it is not up to
this document to specify how the ETHCS transforms a asymmetric ul/dl
multicast feature into a symmetric one.  But it should be a goal for
ETHCS to offer such an interface to the IPv6 stack, otherwise the IPv6
stack won't work.  What do you think?

Alex


_______________________________________________
16NG mailing list
16NG-EgrivxUAwEY@public.gmane.org
https://www1.ietf.org/mailman/listinfo/16ng



Picon

[IPv6 Users] CFP: "IPv6 and the Future of the Internet" workshop <at> SIGCOMM 2007

(excuse me cross posting - hopefully it's not so noisy)

Dear all,

On behalf of the program committee, I'd like to make an announcement
of a CFP for a forthcoming SIGCOMM workshop on IPv6.  Details are
available at http://www.sigcomm.org/sigcomm-conference-current/ipv6/
(major contents of the web page are also pasted below).  Although you
might think SIGCOMM is too "academic" for such practical forums as
IETF, we are actually seeking practical insights as well as
theoretical analyses in this workshop as described in the CFP.
So, please consider submitting a paper on your recent
research/engineering results related to IPv6.

Also, it would be very nice if you can distribute the CFP to whatever
venues that you think are suitable for this workshop.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei <at> isl.rdc.toshiba.co.jp

1. Motivation and rationale for the workshop

This one-day workshop aims to bring together researchers and
practitioners from academia and industry to engage in an in-depth
discussion on various research and deployment issues of IPv6 and their
impact on the future of the Internet. In recent years the global
deployment of IPv6 started taking off, especially in the Asian-Pacific area.
To date IPv6 development efforts have mainly focused on protocol
standardization, product development, and network operations, rather
than as a research target.
However, we believe that the accumulated experiences in these practices
now provide interesting research opportunities, not only for those who
have been involved in IPv6 development but also for the broader network
research community. We expect the workshop to open a dialog between
networking researchers and practitioners, and foster synergistic
activities thereafter.

2. Call for Paper (CFP)

ACM SIGCOMM IPv6 and the Future of the Internet (IPv6+) Workshop seeks
papers describing significant research contributions to the field of
IPv6 and their relevance on the future of the Internet. IPv6 was
primarily motivated by the address shortage problem of IPv4. It provides
a much larger address space than IPv4. However, the competing technology
Network Address Translation (NAT) has alleviated the address shortage
problem to some extent, and other problems, such as routing scalability,
management, mobility, and security, have become increasingly prominent.
At the mean time, the global deployment of IPv6 has gradually taken off.
Modern operating systems are shipped with both IPv4 and IPv6 stacks, and
IPv6-compatible backbones came into existence. As it is costly to
migrate from one network architecture to another one, can we take this
opportunity to address additional problems in the IPv4 Internet by
extending the IPv6 protocol suite? What new problems are/were
encountered in the process of deploying IPv6? And what lessons have we
learned?

We invite submissions that shed light on the above questions.
Submissions in both academic and operational flavors are welcome.
Topics of interest include, but are not limited to:

    * Experiences and lessons learned from pilot deployments of IPv6
      networks and applications
    * Experimental and measurement results from operational IPv6 networks
    * Advantages and challenges the very large IPv6 address space bring
      to the Internet routing system
    * Scalable and robust solutions to multi-homing and traffic engineering
    * Host and Network Mobility
    * Multicast and Anycast protocols
    * Worms, DoS, and other security threats in IPv6 networks and
      possible enhancements to address these challenges.
    * IPv6's Applicability to sensor networks, low-power personal area
      networks, and other types of challenged networks
    * Impact on application development and deployment
    * A critical assessment of IPv6's viability as a global
      communication infrastructure for the future or of its fundamental
      limitations, if any.

3. Submission guideline

Submissions must be no greater than 6 pages in length, must be a pdf
file, and must follow the formatting guidelines at
http://www.sigcomm.org/sigcomm2007/workshop-psg.html. Submissions that
deviate from these guidelines will be rejected without consideration.
Reviews will be single-blind: authors name and affiliation should be
included in the submission. Authors of accepted papers are expected to
present their papers at the workshop. Submissions must be original work
not under review at any other workshop, conference, or journal.

4. Workshop dates

Paper submission due: 		April 6, 2007
Paper acceptance notification: 	May 11, 2007
Camera-ready due: 		June 8, 2007
Workshop: 			Aug 31, 2007

5. Program committee

Program Co-chairs:
        Xiaowei Yang 	UC Irvine, US
  	Tatuya Jinmei 	Toshiba, Japan
  			
Program Committee members:
 	Maoke Chen 	Tsinghua, China
	Kilnam Chon 	KAIST, Korea
  	Rich Draves 	Microsoft, US
  	Paul Francis 	Cornell, US
  	Tony Hain 	Cisco, US
  	Masaki Hirabaru NICT, Japan
  	Xing Li 	Tsinghua, China
  	Yoshifumi Nishida Sony CSL, Japan
  	Pekka Savola 	CSC/FUNET, Finland
  	Dave Thaler 	Microsoft, US
  	Beichuan Zhang 	University of Arizona, US
  	Lixia Zhang 	UCLA, US
_______________________________________________
Users mailing list
Users <at> ipv6.org
https://lists.ipv6.org/mailman/listinfo/users

Picon

Re: [IPv6 Users] CFP: "IPv6 and the Future of the Internet" workshop <at> SIGCOMM 2007

>>>>> On Mon, 15 Jan 2007 01:51:00 +0900, 
>>>>> JINMEI Tatuya <jinmei <at> isl.rdc.toshiba.co.jp> said:

> (excuse me cross posting - hopefully it's not so noisy)

I was reminded that (this type of) conference information was
inappropriate for IETF lists according to the general rule described
in RFC3005.  Of course, I didn't intend to abuse the lists, but
clearly I should have checked the policy more carefully before posting
it.  I'd apologize if any of you felt uncomfortable about the
unsolicited message.  I won't (ab)use IETF lists about subsequent
information (if any) on this matter.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei <at> isl.rdc.toshiba.co.jp

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


Gmane