IPV4 to IPV6

World IPv6 day (Test Flight)

Tukiyooo 0 IPv4/IPv6, IPv6, Setup IPv6, Test Flight 10:27

<div class="_5rgo">
<div class="msg _599f _5tfq">
<div>
Today is the 
World IPv6 day or "Test Flight" day and the goal of the Test Flight Day 
is to motivate organizations across the industry – Internet service 
providers, hardware makers, operating system vendors and web companies –
 to prepare their services for IPv6 to ensure a successful transition as
 IPv4 addresses run out. 
 
Including Google, Facebook, Yahoo!, Akamai and Limelight Networks will offer their contents over IPv6 for 24 hours. 
 
You can check your IPv6 through the <a href="http://lm.facebook.com/l.php?u=http%3A%2F%2Ftest-ipv6.com%2F&h=dAQEBlw_3&s=1" rel="nofollow" target="_blank">http://test-ipv6.com/</a>. 
 
Google has announced that if any problem occured to visit Google then they recommend to use ipv4.google.com rather using <a href="http://lm.facebook.com/l.php?u=http%3A%2F%2Fwww.google.com%2F&h=TAQEEBq0U&s=1" rel="nofollow" target="_blank">www.google.com</a> on june 8. 
 
Although
 you havent IPv6 , its not problem because they are not going to 
completly cwitch to IPv6 , They going to use both IP versions for the 
users on 8 th of june. 
 
you can read  more about google announcement from <a href="http://lm.facebook.com/l.php?u=http%3A%2F%2Fipv4.google.com%2Fsupport%2Fwebsearch%2Fbin%2Fanswer.py%3Fanswer%3D1299266%26topic%3D8995%26hl%3Den&h=LAQEDhFFy&s=1" rel="nofollow" target="_blank">ipv4.google.com/support/websearch/bin/answer.py?answer=1299266&topic=8995&hl=en</a></div>
</div>
</div>

World IPv6 day (Test Flight)

Today is the World IPv6 day or "Test Flight" day and the goal of the Test Flight Day is to motivate organizations across the ...

Solving the IP Address Chicken-and-Egg Challenge

Tukiyooo 0 Challenge, computer, Facebook, hardware manufacturers, IP address, ISPs, mobile phone, OS makers, Solving, Telecom carriers, Web companies 10:25

<a href="https://scontent-b.xx.fbcdn.net/hphotos-xpa1/t1.0-0/165639_494742522199_1812395_n.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" class="img" data-store="{"imgsrc":"https:\/\/scontent-b.xx.fbcdn.net\/hphotos-xpa1\/t1.0-0\/165639_494742522199_1812395_n.jpg"}" height="150" src="https://scontent-b.xx.fbcdn.net/hphotos-xpa1/t1.0-0/165639_494742522199_1812395_n.jpg" width="180" /></a>We’re announcing today our participation in <a href="http://lm.facebook.com/l.php?u=http%3A%2F%2Fwww.isoc.org%2Fworldipv6day&h=DAQErAJSI&s=1" rel="nofollow" target="_blank">World IPv6 Day</a>,
 along with Google, Yahoo!, Akamai, Limelight Networks, and the Internet
 Society. June 8, 2011, will be the first global-scale "test flight" of 
IPv6, the next generation protocol for the Internet. And best of all, 
it’s open to everyone who’s interested in testing their IPv6 service. 
 
This
 is a big step forward for the Internet because the current protocol, 
IPv4 (also known as IP), will run out of addresses this year. Since 
every endpoint on the Internet — whether it’s a computer, mobile phone, 
or TV — relies on a unique IP address to communicate, we need more 
addresses so they can all stay connected. 
 
As a next 
generation protocol, IPv6 provides a vast number of addresses by today's
 standards — 4 billion times the number that are available under IPv4. 
Telecom carriers, ISPs, OS makers, hardware manufacturers, Web 
companies, and governments around the world are depending on IPv6 to 
continue growth of the Internet. World IPv6 Day — a 24 hour period 
during which Internet companies will test IPv6 — is an important step 
that enables the technology to move forward in a globally coordinated 
setting. 
 
Testing IPv6 is important because recent studies 
indicate about 0.05% of Internet users (1 in 2,000) can’t reliably 
connect to websites that enable both IPv4 and IPv6 addresses (known as 
"dual-stacked" websites). This has resulted in a classic chicken-and-egg
 puzzle right now: websites don’t want to enable IPv6 because a small 
number of their users may have trouble connecting. At the same time, 
doing nothing means that ever more users will have trouble connecting to
 these dual-stacked websites, and ISPs will turn to less effective 
technical alternatives like Large Scale NAT (see below). 
 
To
 break this conundrum, we need to take a small, concerted step for just 
24 hours, where Web companies, ISPs, hardware/software makers, and users
 work together and synchronize plans, communication, and support. 
 
Why IPv6 Is Important to Facebook 
The
 switch to IPv6 is especially important for us at Facebook as we pursue 
our mission of helping the world connect and share online. Since last 
summer, we’ve offered Facebook over IPv6 at <a href="http://www.v6.facebook.com/?refid=22" rel="nofollow" target="_blank">www.v6.facebook.com</a>
 (addressed 2620:0:1cfe:face:b00c::3 in true hexadecimal IPv6 hacker 
fashion; note that the v6 link works only from IPv6 endpoints). World 
IPv6 Day will allow us to test our infrastructure and code more widely 
with low risk to our service and users. 
 
The day also 
promotes awareness among hardware and software suppliers, and should 
encourage everyone to create robust IPv6 products and fix buggy ones. 
Between now and June 8th, there’s an opportunity for the entire industry
 to ensure hardware and software isn’t just IPv6-capable, but that it 
can reliably connect people to dual-stacked websites. 
 
This
 year's exhaustion of IPv4 addresses isn’t exactly a sky-is-falling 
situation, because there are always economic and technical solutions 
when there's enough energy put behind a big problem. An economic 
solution is for organizations to buy IPv4 addresses from others willing 
to sell them. But this isn’t a sustainable solution, and it’s perhaps 
not completely fair when you consider how the Internet has historically 
been fully open and accessible. On the technical side, there are many 
protocols and devices in different stages of maturity. But some v4-to-v6
 transitional protocols are so old they are nearly phased-out or 
obsolete. 
 
LSN: A Technical Alternative 
One
 newer solution being proposed is Large Scale NAT (Network Address 
Translation) or LSN, also called Carrier Grade NAT. NAT basically 
translates one address into another, typically a private address into a 
public address and vice-versa. Many users and sites do this today on a 
small scale. Your laptop may have the private address 192.168.1.10, 
which is translated by your home router into a public address provided 
by your ISP. The public address is unique and the address you depend on 
for global Internet connectivity. So what happens when your ISP runs out
 of addresses? Before address exhaustion, it would simply apply for and 
receive new addresses. But that is no longer the case. 
 
<img class="img" data-store="{"imgsrc":"https:\/\/scontent-b.xx.fbcdn.net\/hphotos-xpa1\/t1.0-0\/s280x280\/167495_494743352199_5361035_n.jpg"}" height="171" src="https://scontent-b.xx.fbcdn.net/hphotos-xpa1/t1.0-0/s280x280/167495_494743352199_5361035_n.jpg" width="280" /> 
 
Enter
 LSN. The plan here is to give your endpoint, like your home router, a 
private address instead of a public one and then translate your traffic 
at a new, heavy-duty LSN device that lives elsewhere on the Internet. 
Thus, your laptop's private address will be translated to another 
private address at your home router, which will then be translated again
 into a public address at this new LSN device. Thousands of users share a
 single IP address thanks to the massive translator. What’s unclear is 
whether this will give us the same performance, reliability, and 
security we have on the Internet today. And the people deploying LSN are
 not exactly thrilled about having to use it — it's more out of 
necessity because most websites aren’t yet dual-stacked to handle an 
end-to-end IPv6 connection. 
 
IPv6 vs. LSN 
Many
 people have spent years working IPv6, which is a longer-term and more 
reliable solution than LSN. Adopting IPv6 means that people with IPv6 
addresses can talk to IPv6-enabled, dual-stack sites without 
translators. The following chart describes some other aspects of LSN 
compared to end-to-end IPv6 connectivity. 
 
<img class="img" data-store="{"imgsrc":"https:\/\/scontent-b.xx.fbcdn.net\/hphotos-xfa1\/t1.0-0\/s280x280\/166116_494743382199_4204840_n.jpg"}" height="183" src="https://scontent-b.xx.fbcdn.net/hphotos-xfa1/t1.0-0/s280x280/166116_494743382199_4204840_n.jpg" width="280" /> 
 
We
 hope you'll follow along in the coming months and then join us for 
World IPv6 Day on June 8, 2011, when the Internet takes a big step 
forward! 
 
Acknowledgements 
Many people contributed to our IPv6 efforts and this event, notably <a href="http://www.facebook.com/wlawton?refid=22" rel="nofollow" target="_blank">Will Lawton</a>, <a href="http://www.facebook.com/ps?refid=22" rel="nofollow" target="_blank">Paul Saab</a>, <a href="http://www.facebook.com/jallen?refid=22" rel="nofollow" target="_blank">John Allen</a>, and <a href="http://www.facebook.com/jonnythaw?refid=22" rel="nofollow" target="_blank">Jonny Thaw</a> at Facebook, Lorenzo Colitti at Google, and Tore Anderson at Redpill Linpro.

Solving the IP Address Chicken-and-Egg Challenge

We’re announcing today our participation in World IPv6 Day , along with Google, Yahoo!, Akamai, Limelight Networks, and the Internet Socie...

C++ Internet Protocol and Socket Address Classes

Tukiyooo 0 C++, Internet, IP address, IPv4, IPv4/IPv6, IPv6, Protocol, Socket 19:18

<pre>C++ Internet Protocol and Socket Address Classes

Document Number: TBD
Date: TBD
Author: Aleksandar Fabijanic <alex AT pocoproject.org>
 Günter Obiltschnig <guenter.obiltschnig AT appinf.com>

Content

1. Revision History

2. Motivation and Scope

3. IP Address
 3.1. Usage Examples
 3.1.1. IPv4
 3.1.2. IPv6
 3.2. Header <ip_address> synopsis

5. Socket Address
 5.1. Usage Examples
 5.2. Header <socket_address> synopsis

6. Conclusion

7. Acknowledgments

1. Revision History

- Oct 10 2012: created

2. Motivation and Scope

Given the pervasiveness of networking and Internet, there is a
pressing need for standard networking support in C++ language.
This proposal addresses the concerns of IP and socket addresses;
it is aimed to be one of the fundamental building blocks and
steps toward the Standard C++ Network Library goal.

This proposal is based on IP and socket address implementations
in the Net library in C++ Portable Components (POCO) [6] framework.
POCO framework has been open sourced in 2005 by its principal
sponsor (Applied Informatics Software Engineering GmbH) and is
currently licensed under Boost Software License and used in
production by numerous commercial entities as well as other
open source projects [7].

The scope of the proposal is description of functionality,
interfaces and usage examples for a set of classes providing
functionality to store and manipulate Internet Protocol
(IPv4 and v6) as well as socket (IP address + port) addresses.

3. IP Address

The ip_address class represents an Internet Protocol host
address. The address can belong to either IPv4 or IPv6 
(if the target platform supports it) address family.

Relational operators (==, !=, <, <=, >, >=) are supported. 
Notably, an IPv4 address is never equal to an IPv6 
address, even if the IPv6 address is IPv4 compatible and 
the addresses are logically the same.

For underlying IP address bit manipulation, bitwise operators
(&, |, ^, ~) are supported.

3.1 Usage Examples

3.1.1. IPv4:

ip_address ia("127.0.0.1");
assert (ia.family() == ip_address::ipv4);
assert (ia.to_string() == "127.0.0.1");
assert (ip.is_loopback());

ip_address addr("10.0.0.51");
ip_address mask(24, ip_address::ipv4);
assert(mask.prefix_len() == 24);

ip_address net = addr & mask;
assert(net.to_string() == "10.0.0.0");

ip_address host("0.0.0.51");
assert((net | host) == addr);
assert((~mask).to_string() == "0.0.0.255");

3.1.2. IPv6

ip_address ia("1080:0:0:0:8:600:200a:425c");
assert (ia.family() == ip_address::ipv6);
assert (ia.to_string() == "1080::8:600:200a:425c");

ip_address ia(62, ip_address::ipv6);
assert(ia.to_string() == "ffff:ffff:ffff:fffc::");

3.2. Header <ip_address> synopsis

namespace std {
namespace net {

typedef int socklen_t;

class ip_address {
public:
typedef std::vector<IPAddress> list;

enum family
/// Possible address families for IP addresses.
{
 ipv4
#ifdef _STD_HAVE_IPv6
 ,ipv6
#endif
};
 
ip_address();
 /// Creates a wildcard (zero) IPv4 ip_address.

ip_address(const ip_address& addr);
 /// Creates an ip_address by copying another one.

explicit IPAddress(family family);
 /// Creates a wildcard (zero) ip_address for the given address family.

explicit ip_address(const std::string& addr);
 /// Creates an IPAddress from the string containing
 /// an IP address in presentation format (dotted decimal
 /// for IPv4, hex string for IPv6).
 /// Depending on the format of addr, IPv4 or an IPv6 address is 
 /// created. See to_string() for details on the supported formats.
 /// Throws std::runtime_exception if the address cannot be parsed.

ip_address(const std::string& addr, Family family);
 /// Creates an ip_address from the string containing
 /// an IP address in presentation format (dotted decimal
 /// for IPv4, hex string for IPv6).

ip_address(const void* addr, socklen_t length);
 /// Creates an IPAddress from a native internet address.
 /// A pointer to an in_addr or an in6_addr structure may be passed.

ip_address(const void* addr, socklen_t length, uint32_t scope);
 /// Creates an IPAddress from a native internet address.
 /// A pointer to a in_addr or a in6_addr structure may be 
 /// passed. Additionally, for an IPv6 address, a scope ID
 /// may be specified. The scope ID will be ignored if an IPv4
 /// address is specified.

ip_address(uint32_t prefix, family family);
 /// Creates an ip_address mask with the given length of prefix.

ip_address(const struct sockaddr& sockaddr);
 /// Creates an ip_address from sockaddr structure.

~ip_address();
 /// Destroys the IPAddress.

ip_address& operator = (const ip_address& addr);
 /// Assigns an IPAddress.
  
void swap(ip_address& address);
 /// Swaps the IPAddress with another one.
  
family family() const;
 /// Returns the address family (ipv4 or ipv6) of the address.

uint32_t scope() const;
 /// Returns the IPv6 scope identifier of the address. Returns 0 if
 /// the address is an IPv4 address, or the address is an
 /// IPv6 address but does not have a scope identifier.

std::string to_string() const;
 /// Returns a string containing a representation of the address
 /// in presentation format.
 /// For IPv4 addresses the result will be in dotted-decimal (d.d.d.d) notation.
 /// The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal 
 /// values of the eight 16-bit pieces of the address. This is the full form.
 /// Example: 1080:0:0:0:8:600:200a:425c
 /// It is not necessary to write the leading zeros in an individual field. 
 /// However, there must be at least one numeral in every field, except as 
 /// described below.
 /// It is common for IPv6 addresses to contain long strings of zero bits. 
 /// In order to make writing addresses containing zero bits easier, a special
  /// syntax is  available to compress the zeros. The use of "::" indicates multiple
 /// groups of 16-bits of zeros. 
 /// The "::" can only appear once in an address. The "::" can also be used to 
 /// compress the leading and/or trailing zeros in an address. 
 /// Example: 1080::8:600:200a:425c
 /// For dealing with IPv4 compatible addresses in a mixed environment,
 /// a special syntax is available: x:x:x:x:x:x:d.d.d.d, where the 'x's are the 
 /// hexadecimal values of the six high-order 16-bit pieces of the address, 
 /// and the 'd's are the decimal values of the four low-order 8-bit pieces of the 
 /// standard IPv4 representation address. Example: ::ffff:192.168.1.120
 /// If an IPv6 address contains a non-zero scope identifier, it is added
 /// to the string, delimited by a percent character. On Windows platforms,
 /// the numeric value (which specifies an interface index) is directly
 /// appended. On Unix platforms, the name of the interface corresponding
 /// to the index (interpretation of the scope identifier) is added.

bool is_wildcard() const;
 /// Returns true iff the address is a wildcard (all zero) address.
  
bool is_broadcast() const;
 /// Returns true iff the address is a broadcast address.
 /// Only IPv4 addresses can be broadcast addresses. In a broadcast
 /// address, all bits are one. For an IPv6 address, returns always false.
 
bool is_loopback() const;
 /// Returns true iff the address is a loopback address.
 /// For IPv4, the loopback address is 127.0.0.1.
 /// For IPv6, the loopback address is ::1.
 
bool is_multicast() const;
 /// Returns true iff the address is a multicast address.
 /// IPv4 multicast addresses are in the
 /// 224.0.0.0 to 239.255.255.255 range
 /// (the first four bits have the value 1110).
 /// IPv6 multicast addresses are in the
 /// FFxx:x:x:x:x:x:x:x range.
  
bool is_unicast() const;
 /// Returns true iff the address is a unicast address.
 /// An address is unicast if it is neither a wildcard,
 /// broadcast or multicast address.
  
bool is_link_local() const;
 /// Returns true iff the address is a link local unicast address.
 /// IPv4 link local addresses are in the 169.254.0.0/16 range,
 /// according to RFC 3927.
 /// IPv6 link local addresses have 1111 1110 10 as the first
 /// 10 bits, followed by 54 zeros.
  
bool is_site_local() const;
 /// Returns true iff the address is a site local unicast address.
 /// IPv4 site local addresses are in on of the 10.0.0.0/24,
 /// 192.168.0.0/16 or 172.16.0.0 to 172.31.255.255 ranges.
 /// Originally, IPv6 site-local addresses had FEC0/10 (1111 1110 11) 
 /// prefix (RFC 4291), followed by 38 zeros. Interfaces using  
 /// this mask are supported, but obsolete; RFC 4193 [3] prescribes
 /// fc00::/7 (1111 110) as local unicast prefix.
  
bool is_ipv4_compatible() const;
 /// Returns true iff the address is IPv4 compatible.
 /// For IPv4 addresses, this is always true.
 /// For IPv6, the address must be in the ::x:x range (the
 /// first 96 bits are zero).

bool is_ipv4_mapped() const;
 /// Returns true iff the address is an IPv4 mapped IPv6 address.
 /// For IPv4 addresses, this is always true.
 /// For IPv6, the address must be in the ::FFFF:x:x range.
 
bool is_well_known_mcast() const;
 /// Returns true iff the address is a well-known multicast address.
 /// For IPv4, well-known multicast addresses are in the 224.0.0.0/8 range.
 /// For IPv6, well-known multicast addresses are in the 
 /// FF0x:x:x:x:x:x:x:x range.
 
bool is_node_local_mcast() const;
 /// Returns true iff the address is a node-local multicast address.
 /// IPv4 does not support node-local addresses, thus the result is
 /// always false for an IPv4 address.
 /// For IPv6, node-local multicast addresses are in the
 /// FFx1:x:x:x:x:x:x:x range.
 
bool is_link_local_mcast() const;
 /// Returns true iff the address is a link-local multicast address.
 /// For IPv4, link-local multicast addresses are in the
 /// 224.0.0.0/24 range. Note that this overlaps with the range for well-known
 /// multicast addresses.
 /// For IPv6, link-local multicast addresses are in the
 /// FFx2:x:x:x:x:x:x:x range.

bool is_site_local_mcast() const;
 /// Returns true iff the address is a site-local multicast address.
 /// For IPv4, site local multicast addresses are in the 239.255.0.0/16 range.
 /// For IPv6, site-local multicast addresses are in the
 /// FFx5:x:x:x:x:x:x:x range.

bool is_org_local_mcast() const;
 /// Returns true iff the address is a organization-local multicast address.
 /// For IPv4, organization-local multicast addresses are in the
 /// 239.192.0.0/16 range.
 /// For IPv6, organization-local multicast addresses are in the
 /// FFx8:x:x:x:x:x:x:x range.

bool is_global_mcast() const;
 /// Returns true iff the address is a global multicast address.
 /// For IPv4, global multicast addresses are in the 
 /// 224.0.1.0 to 238.255.255.255 range.
 /// For IPv6, global multicast addresses are in the
 /// FFxF:x:x:x:x:x:x:x range.
 
bool operator == (const ip_address& addr) const;
 /// Returns true if IP addresses are equal.

bool operator != (const ip_address& addr) const;
 /// Returns true if IP addresses are not equal.

bool operator < (const ip_address& addr) const;
 /// Returns true if this IP address is lesser than addr.

bool operator <= (const ip_address& addr) const;
 /// Returns true if this IP address is lesser than or equal to addr.

bool operator >  (const ip_address& addr) const
 /// Returns true if this IP address is greater than addr.

bool operator >= (const ip_address& addr) const;
 /// Returns true if this IP address is greater than or equal to addr.

ip_address operator & (const ip_address& addr) const;
 /// Performs a bitwise ANd operation and returns result.

ip_address operator | (const ip_address& addr) const;
 /// Performs a bitwise OR operation and returns result.

ip_address operator ^ (const ip_address& addr) const;
 /// Performs a bitwise XOR operation and returns result.

ip_address operator ~ () const;
 /// Performs a bitwise NOT operation on this IP address and returns result.
  
socklen_t length() const;
 /// Returns the length in bytes of the internal socket address structure. 
  
const void* addr() const;
 /// Returns the internal address structure.
  
uint32_t af() const;
 /// Returns the address family (AF_INET or AF_INET6) of the address.

unit32_t prefix_len() const;
 /// Returns the prefix length.
  
void mask(const ip_address& mask);
 /// Masks the IP address using the given netmask, which is usually
 /// a IPv4 subnet mask. Only supported for IPv4 addresses.
 /// The new address is (address & mask).
  
void mask(const ip_address& mask, const ip_address& set);
 /// Masks the IP address using the given netmask, which is usually
 /// a IPv4 subnet mask. Only supported for IPv4 addresses.
 /// The new address is (address & mask) | (set & ~mask).
  
static ip_address assign(const std::string& addr);
 /// Creates an IPAddress from the string containing
 /// an IP address in presentation format (dotted decimal
 /// for IPv4, hex string for IPv6).
 /// Depending on the format of addr, either an IPv4 or
 /// an IPv6 address is created.
 /// See to_string() for details on the supported formats.
 /// Throws std::runtime_exception if the address cannot be parsed.

static bool try_assign(const std::string& addr, IPAddress& result);
 /// Tries to interpret the given address string as an
 /// IP address in presentation format (dotted decimal
 /// for IPv4, hex string for IPv6).
 /// Returns true and stores the IPAddress in result if the
 /// string contains a valid address.
 /// Returns false and leaves result unchanged otherwise.

static IPAddress wildcard(Family family = ipv4);
 /// Returns a wildcard IPv4 or IPv6 address.
  
static IPAddress broadcast();
 /// Returns a broadcast IPv4 address (255.255.255.255).
};
}} // namespace std::net

4. Socket Address

This class represents an internet (IP) endpoint/socket address. The address
can belong either to the IPv4 or the IPv6 address family and consists of a
host IP  address and a port number.

4.1 Usage Examples

socket_address wild;
assert (wild.host().is_wildcard());
assert (wild.port() == 0);

socket_address sa1("192.168.1.100", 100);
assert (sa1.host().to_string() == "192.168.1.100");
assert (sa1.port() == 100);

socket_address sa2("192.168.1.100", "100");
assert (sa2.host().to_string() == "192.168.1.100");
assert (sa2.port() == 100);

socket_address sa3("192.168.1.100", "ftp");
assert (sa3.host().to_string() == "192.168.1.100");
assert (sa3.port() == 21);

socket_address sa4("www.appinf.com", 80);
assert (sa4.host().toString() == "50.57.108.29");
assert (sa4.port() == 80);

4.2 Header <socket_address> synopsis

namespace std {
namespace net {
class socket_address
 /// This class represents an (IP) socket address.
 /// The address can belong either to the IPv4 or the IPv6 address
 /// family and consists of a host address and a port number.
{
public:
socket_address();
 /// Creates a wildcard (all zero) IPv4 socket_address.

socket_address(const ip_address& host, uint_16t port);
 /// Creates a socket_address from an IP address and a port number.

socket_address(const std::string& host, uint_16t port);
 /// Creates a socket_address from an IP address and a port number.
 /// The IP address must either be a domain name, or it must
 /// be in dotted decimal (IPv4) or hex string (IPv6) format.

socket_address(const std::string& host, const std::string& port);
 /// Creates a socket_address from an IP address and a
 /// service name or port number.
 /// The IP address must either be a domain name, or it must
 /// be in dotted decimal (IPv4) or hex string (IPv6) format.
 /// The given port must either be a decimal port number, or
 /// a service name (as typically returned in struct servent
 /// by the getservbyname() call.

explicit socket_address(const std::string& host_and_port);
 /// Creates a socket_address from an IP address or host name and a
 /// port number/service name. Host name/address and port number
 /// must be separated by a colon. In case of an IPv6 address, the
 /// address part must be enclosed in brackets.
 /// 
 /// Examples:
 ///     192.168.1.10:80
 ///     [::ffff:192.168.1.120]:2040
 ///     www.appinf.com:8080

socket_address(const socket_address& addr);
 /// Creates a socket_address by copying another one.

socket_address(const struct sockaddr* addr, socklen_t length);
 /// Creates a socket_address from a native socket address.

~socket_address();
 /// Destroys the socket_address.

socket_address& operator = (const socket_address& addr);
 /// Assigns another socket_address.

void swap(socket_address& addr);
 /// Swaps the socket_address with another one.

ip_address host() const;
 /// Returns the host IP address.

uint_16t port() const;
 /// Returns the port number.

socklen_t length() const;
 /// Returns the length of the internal native socket address.

const struct sockaddr* addr() const;
 /// Returns a pointer to the internal native socket address.

uint32_t af() const;
 /// Returns the address family (AF_INET or AF_INET6) of the address.

std::string to_string() const;
 /// Returns a string representation of the address.

ip_address::family family() const;
 /// Returns the address family of the host's address.

bool operator < (const socket_address& addr) const;
 /// Less than operator.

bool operator == (const socket_address& addr) const;
 /// Equal operator.

bool operator != (const socket_address& addr) const;
 /// Not equal operator.

};
}} // namespace std::net

6. Conclusion

Class interfaces for IP and socket address as well as rationale for their 
introduction in C++ Standard and usage examples were described in this 
proposal. This proposal is one of the starting points and building blocks 
for C++ Standard Networking Library. Implementation of the described 
functionality is currently available in POCO framework [6]; the 
implementation differs in naming scheme from this proposal. Given a 
positive feedback on the proposal, implementation  will be available 
in the near future as a standalone implementation in standard-compliant 
naming convention, with accompanying tests and code examples.

7. Acknowledgements

POCO original author (Günter Obiltschnig)
POCO project contributors and users

References

[1] RFC 791
[2] RFC 2460
[3] RFC 4193
[4] RFC 3513
[5] RFC 3879
[6] C++ Portable Components: http://pocoproject.org
[7] List of known POCO users: http://pocoproject.org/forum/viewtopic.php?f=11&t=3826

C++ Internet Protocol and Socket Address Classes

C++ Internet Protocol and Socket Address Classes Document Number: TBD Date: TBD Author: Aleksandar Fabijanic <alex AT pocoproject.or...

What is tunneltrace?

Tukiyooo 0 Internet Protocol Version4 and IPv6, IPv4/IPv6, protocolos DNS (sistema de nombre de dominio) en linux y en windows protocolos DNS, tunnels, tunneltrace 19:15

TUNNELTRACE-RS v1.0                                =================== What is tunneltrace? -------------------- Tunneltrace is a tool used for detecting IPv6 in IPv4 tunnels. More precisely, Tunneltrace can run in 2 modes: Mode 1:   Given two IPv4 Addresses it checks if there is a tunnel between them. If there is evidence of the presence of a tunnel, tunneltrace outputs a confidence value, which provides a measure of the probability that the tunnel exists, and tries to determine the IPv6 addresses of the endpoints. Mode 2:   Tunneltrace can also determine, given an IPv6 Address, the full Path from the node where tunneltrace is launched to the given address. From the Path determined tunneltrace identifies the Path MTU and all the tunnels inside the path, and for each tunnel found it tries to find the IPv4 addresses of the endpoints and outputs a confidence value. Techniques used --------------- Tunneltrace uses three techniques to detect tunnels: 1) IPv4 spoofing 2) DNS lookups 3) Queries to the 6bone registry Each of the above techniques has a degree of confidence. The confidence value output by tunneltrace is the sum of the confidence values of each technique that succeeded. Brief description of the techniques ----------------------------------- 1. IPv4 spoofing These are the main techniques used by tunneltrace. By encapsulating an IPv6 packet in an IPv4 packet having the source address of one of the tunnel endpoints, tunneltrace can trick the other endpoint into treating the packet as if it had come from the tunnel. Tunneltrace uses four spoofing techniques:     a) Injected Ping        Encapsulated IPv6 echo request to a pingable IPv6 interface. Used to        determine if there is a tunnel.     b) Dying Packet        Similar to the above, but injects packets with a Hop Count field of 1.        Used to determine the IPv6 addresses of the tunnel endpoints.     c) Ping Pong Packet        Similar to the above, but attempts to determine the address of one        endpoint if the address of the other endpoint is known.     d) Fragmented Injection        As Injected Ping but puts the IPv6 echo request message into three IPv4 fragments 2. DNS Lookups Looks for AAAA records with the endpoint hostnames, if we are running tunneltrace in mode 1. Looks for A records with the endpoint hostnames (retreived by a reverse-lookup),if we are running tunneltrace in mode 2. 3. Queries to the 6bone registry Looks for a corresponding entry in the 6bone registries. Tunneltrace requires a copy of the 6bone registry file to be stored locally in /etc/6bone.db or in the directory where tunneltrace is installed. You may download this file from ftp://whois.6bone.net/6bone/6bone.db.gz A detailed description of the techniques used can be found in the papers available at the URL: http://www.dia.uniroma3.it/~compunet/tunneldiscovery/tunneling-noms.pdf 4) Path MTU Discovery Tunneltrace tries to send ICMPv6 packets with the MTU of the node where it is running and using Hop Limit manipulation for determining the Path (Modifing the HL field). If it receives a ICMPv6 message of Packet-Too-Big, from that point on it will send packets with the MTU specified in the Packet-Too-Big messagge, until it doesn't receive antoher packet too big messagge, and so on. 5) Fragmented IPv6 in IPv4 Path MTU Discovery If Tunneltrace finds on its Path a Tunnel, it tryes to use the outern endpoint of it as Vantage Point for Path MTU Discovery , by creating an IPv6 Packet of the MTU of the source node in IPv4 Fragments of 68 bytes. So to be able to do Path MTU Discovery (and PATH TRACING with Hop Limit manipulation) from the Vantage Point. This repeatably for every new Vantage Point that Tunneltrace finds further on in the Path. How confidence values are calculated ------------------------------------ The Confidence value output by tunneltrace is calculated using the following criteria: Spoofing Techniques ->   Injected Ping success on 1 Endpoint only  : 5 Confidence Points    Injected Ping success of both Endpoints   : 7 Confidence Points   Dying Packet success on each Endpoint     : 1 Confidence point   Ping Pong Packet success on one Endpoint (if Dying Packet didn't work)                                             : 1 Confidence point If Spoofing Techniques succeeded, then ->   6bone registries lookup success           : 1 Confidence points If no Spoofing Technique succeeded, then ->   DNS lookups success                             : 1 Confidence points   6bone registries lookup success           : 4 Confidence points Compiling tunneltrace --------------------- To compile tunneltrace, run the build.sh script in the distribution. Compilation requires the C++ development libraries to be installed. Tunneltrace is known to compile on Linux and FreeBSD, but should also compile and run on other platforms such as Solaris. Tunneltrace runs on both littleEndian and bigEndian machines. Using tunneltrace ----------------- 1. Prerequisites Due to the use of spoofing techniques that require raw sockets, you must be root to run tunneltrace. Some of the techniques used by tunneltrace require a reference IPv6 address. This address must be globally routed or, at a minimum, reachable from the tunnel endpoints. The reference IPv6 address may be specified on the command line using the -h parameter or in the file /etc/tunneltrace.ip. As stated previously, tunneltrace also requires a 6bone registry dump in the file /etc/6bone.db or in the directory where tunneltrace is installed. You may run multiple istances of tunneltrace in parallel, since each one recognizes its own packets. 2. Usage Tunneltrace's syntax is the following : Mode 1: tunneltrace [ -h reference IPv6 ] [ -v ] <source IPv4> <dest IPv4>     Where <source IPv4> AND <dest IPv4>: IPv4 addresses or hostnames Mode 2: tunneltrace [ -h reference IPv6 ] <dest IPv6>     Where <dest IPv6>: IPv6 address or hostname Tunneltrace exits with an error if <source IPv4> or <dest IPv4> are not valid IPv4 addresses or resolvable hostnames or if the reference IPv6 is not a valid IPv6 address or <dest IPv6> is not a valid IPv6 address or resolvable hostname or is not reachable. The -v option is used for generating Parametric OUTPUT (on one line) in order to see the techniques that worked in detail Output format ------------- The output format of tunneltrace is the following: Mode 1: # tunneltrace <source IPv4> <dest IPv4> source_host(source_IPv4) -> dest_host(dest_IPv4) source_IPv6 -> dest_IPv6 ; CONFIDENCE X/10 Mode 2: # tunneltrace <dest IPv6> 1         host_1(IPv6_1)  MTU 2         host_2(IPv6_2)  MTU source_host1(source_IPv4_1) -> dest_host2(dest_IPv4_2) source_IPv6_1 -> dest_IPv6_2 ; CONFIDENCE X/10 3         host_3(IPv6_3)  MTU . . 8         host_dest(IPv6_dest)  MTU If none of the techniques worked, tunneltrace will output a confidence value of zero and one or both of the IPv6 addresses will be shown as "unknown". Credits ------- Tunneltrace was developed as part of Davide De Micco's master thesis in collaboration with the Computer Networks research group at Roma Tre University. Contributors are: Davide De Micco Lorenzo Colitti Giuseppe Di Battista Emanuele Conti Maurizio Patrignani

What is tunneltrace?

TUNNELTRACE-RS v1.0 =================== What is tunneltrace? -----------------...

How to add IPv6 over IPv4 support to your network behind a NAT router

Tukiyooo 0 IPv4, IPv4/IPv6, IPv6, router, Setup IPv6 19:12

<pre>Firewall+IPv6 Tunnel mini-HOWTO
Hernán Freschi <hjf(at)hjf.com.ar>
version 0.1, 2002-11-27

How to add IPv6 over IPv4 support to your network behind a NAT router.
----------------------------------------------------------------------

Table of Contents

1. Introduction

1.1 Copyright
     1.2 Disclaimer
     1.3 Credits
     1.4 Changelog
  
  2. What's IPv6? What can it do for me?

3. How do I connect to the 6bone?

4. What should I allow through the firewall?

5. Configuring the IPv6 machines/routers

5.1. Linux

5.2. Windows

5.2.1 IPv6 stand-alone machine
    5.2.2 IPv6 network
      5.2.2.1 The Router
      5.2.2.2 The clients

6. Examples
     6.1 Windows PC using IPv6, behind iptables NAT/MASQ, with a tunnel from HE.
     6.2 Multiple Windows PCs using IPv6, behind iptables NAT/MASQ, with a tunnel from BTExact.

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

1. Introduction

1.1 Copyright

This document is Copyright 2002 by Hernán Freschi. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found at www.gnu.org.

1.2 Disclaimer 
Use the information in this document at your own risk. I disavow any potential liability for the contents of this document. Use of the concepts, examples, and/or other content of this document is entirely at your own risk.

All copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.

Naming of particular products or brands should not be seen as endorsements.

You are strongly recommended to take a backup of your system before major installation and backups at regular intervals.

1.3 Credits

Hernán Freschi <hjf(at)hjf.com.ar>

Microsoft, Windows, 2000, XP, SP1, .NET Server 2003 are all trademarks of Microsoft Corp.

Any comments or suggestions can be mailed to my mail address on: hjf(at)hjf.com.ar

This document is still in beta phase, so errors and omissions may be present.

1.4 Changelog

0.1 Initial Release.

Getting Started

2. What's IPv6? What can it do for me?

Sorry, that is beyond the scope of this document. This aims to make a iptables firewall to allow incoming traffic from an IPv6 tunnel.

3. How do I connect to the 6bone?

Through a tunnel broker!. Get your account (for free) at:

www.tunnelbroker.net (USA)
tb.ipv6.btexact.com (UK)
tb.ngnet.it (Italy?)

You could also use www.freenet6.net, but they use proprietary software, which doesn't run inside a network. But it's easier to implement and even assigns /48 subnets.

4. What should I allow through the firewall?

Everything that comes from the tunnel address, except ICMP (what for? let the linux box answer, so the packets dont get in the network). The rules I use are this:

iptables -A FORWARD -s <tunnel address> -p ! ICMP -i eth0 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -j DNAT --to <internal router address>

And that's it. The outgoing packets don't need special treatment.

Note: This, of course, assumes that your Linux firewall doesn't handle the IPv6 packets. It's designed to run on tiny distros like FloppyFW (www.zelow.no/floppyfw) or LRP (www.lrp.org). With this, the firewall doesn't need support for IPv6. These packets are handled in an internal, more powerful (ie: with a hard disk) computer.

5. Configuring the IPv6 machines/routers

5.1 Linux

I don't have a linux box to experiment, you can either
a) Donate a hard disk, so I can install linux again or
b) Write this section for me :)

5.2 Windows (2000/XP/XP-SP1/.NET Server 2003 ONLY! Win9x is UNSUPPORTED).

First of all, you have to install IPv6 support:

C:\> ipv6 install
Installing...

Success.

5.2.1 IPv6 stand-alone machine:

Use your brokers script! If they didn't provide one, use these:

ipv6.exe rtu ::/0 2/::<tunnel address>
ipv6.exe adu 2/<your ipv6 address>

The 2/ is the Interface Index. It's usually 2, but it may vary. If in doubt, type

ipv6 if

and look for a line like this:

Interface 2: Automatic tunnel pseudo-interface

The number, obviously, is the one you are looking for.

5.2.2 IPv6 network

(Note: this applies only to the external network. If you need help setting up the IPv6 lan, read www.microsoft.com/ipv6)

5.2.2.1 The Router

Use your brokers script! If they didn't provide one, use these:

ipv6.exe rtu ::/0 2/::<tunnel address>
ipv6.exe adu 2/<your ipv6 address>
ipv6.exe rtu <your ipv6 subnet>/<your ipv6 netmask> 4 pub life 86400
ipv6.exe ifc 2 forw
ipv6.exe ifc 3 forw
ipv6.exe ifc 4 forw adv

2, 3, 4 are the interface indices. They may vary. To find out, type

ipv6 if

5.2.2.2 The clients

You don't need to do nothing, they are auto configured.

6. Examples:

6.1 Windows PC using IPv6, behind iptables NAT/MASQ, with a tunnel from HE.

Equipment required:
1 Box capable of running iptables (kernel = 2.4.x)
1 Box running Microsoft® Windows 2000, Windows XP (SP1), Windows .NET Server 2003.

Tunnel:
1 /127 Allocation from Hurricane Electric

+---+ +---+ \/\/\/\/\/ +------+ /\/\/\/\/\
 |WIN|------------|FFW|-----------/INTERNET\---------|TUNNEL|----------\ 6bone /
 +---+ +---+ \/\/\/\/\/ +------+ /\/\/\/\/\
10.42.42.100<->10.42.42.1 <-> 209.13.122.2 <-> ipv6.he.net <-> 2001:470:1F00:FFFF::xxxx

Configuration:
On the Linux box type:

iptables -A FORWARD -s 64.71.128.82 -p ! ICMP -i eth0 -j ACCEPT
iptables -t nat -A PREROUTING -s 64.71.128.82 -i eth0 -j DNAT --to 10.42.42.100

On the MS box type:

ipv6 rtu ::/0 2/::64.71.128.82 pub
ipv6 adu 2/2001:470:1F00:FFFF::xxxx

Congratulations. You are set.

Now try pinging to 6bone.net, for example.

6.2 Multiple Windows PCs using IPv6, behind iptables NAT/MASQ, with a tunnel from BTExact.

Equipment required:
1 Box capable of running iptables (kernel = 2.4.x)
n Boxes running Microsoft® Windows 2000, Windows XP (SP1), Windows .NET Server 2003.

Tunnel:
1 /64 Allocation from Hurricane Electric

+---+ +---+ +---+
  |WIN| |WIN| |WIN|
  +---+ +---+ +---+
    +-----+-----+
  +---+            +---+           \/\/\/\/\/         +------+          /\/\/\/\/\
--|WRT|------------|FFW|-----------/INTERNET\---------|TUNNEL|----------\  6bone /
  +---+            +---+           \/\/\/\/\/         +------+          /\/\/\/\/\

10.42.42.100<->10.42.42.1 <-> 209.13.122.2 <-> 193.113.58.80 <-> 2001:618:400::xxxx:xxxx

Configuration:
On the Linux box type:

iptables -A FORWARD -s 64.71.128.82 -p ! ICMP -i eth0 -j ACCEPT
iptables -t nat -A PREROUTING -s 64.71.128.82 -i eth0 -j DNAT --to 10.42.42.100

On the MS router type:

ipv6.exe rtu ::/0 2/::193.113.58.80
ipv6.exe adu 2/2001:618:400::xxxx:xxxx
ipv6.exe rtu 2001:618:400:xxxx::/64 4 pub life 86400
ipv6.exe ifc 2 forw
ipv6.exe ifc 3 forw
ipv6.exe ifc 4 forw adv

On the other machines type:

Nothing, they are auto configured. If they dont work, try:

ipv6 reset

If that doesn't work, check for a default route (::/0).

ipv6 rt

If there isn't one, try adding one:

ipv6 rtu ::/0 n/(your routers ipv6 address)

(where n is the interface index of the ethernet board connected to the network, usually 4).

If it works, but the next time you reboot, it does not auto configure, then maybe you are not publishing the default route in the router.

Congratulations. You are set.

Now try pinging to 6bone.net, for example. 
</pre>

How to add IPv6 over IPv4 support to your network behind a NAT router

Firewall+IPv6 Tunnel mini-HOWTO Hernán Freschi <hjf(at)hjf.com.ar> version 0.1, 2002-11-27 How to add IPv6 over IPv4 support to your ...

IPv6 multicast address assignment with DHCPv6

Tukiyooo 0 DHCP, DHCPv6, IPv6, Setup IPv6 19:10

<pre>Network Working Group J. Durand
Internet-Draft GIP RENATER
Expires: August 19, 2005 February 18, 2005

IPv6 multicast address assignment with DHCPv6
           draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01

Status of this Memo

By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 19, 2005.

Abstract

This document proposes a simple solution to solve IPv6 multicast
   address assignment problem using the DHCPv6 protocol.

Durand                  Expires August 19, 2005                 [Page 1]
 
Internet-Draft    IPv6 multicast address assignment with DHCPv6        February 2005

Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   IPv6 multicast deployment status . . . . . . . . . . . . .  3
     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3   SSM: no solution needed  . . . . . . . . . . . . . . . . .  3
     1.4   Session announcement considerations  . . . . . . . . . . .  4
   2.  State of the art for address assignment  . . . . . . . . . . .  4
   3.  Assignment with DHCPv6 . . . . . . . . . . . . . . . . . . . .  4
     3.1   New DHCPv6 options . . . . . . . . . . . . . . . . . . . .  4
       3.1.1   IA_MA option for IPv6 Multicast Addresses  . . . . . .  4
       3.1.2   Scope Option for IPv6 multicast address  . . . . . . .  6
     3.2   Address timers . . . . . . . . . . . . . . . . . . . . . .  6
     3.3   Assignment of a multicast prefix . . . . . . . . . . . . .  7
     3.4   Client and server behavior . . . . . . . . . . . . . . . .  7
   4.  Group-ID consideration . . . . . . . . . . . . . . . . . . . .  8
   5.  Deployment scenarios - Case studies  . . . . . . . . . . . . .  8
     5.1   Scenario 1: Site deployment  . . . . . . . . . . . . . . .  8
     5.2   Scenario 2: Campus deployment  . . . . . . . . . . . . . .  9
     5.3   Scenario 3: ISP deployment . . . . . . . . . . . . . . . .  9
   6.  Security considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Discussions  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . 10
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 10
   10.1  Normative references . . . . . . . . . . . . . . . . . . . . 10
   10.2  Informative references . . . . . . . . . . . . . . . . . . . 11
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
       Intellectual Property and Copyright Statements . . . . . . . . 13

Durand                  Expires August 19, 2005                 [Page 2]
 
Internet-Draft    IPv6 multicast address assignment with DHCPv6        February 2005

1.  Introduction

Embedded-RP [11] is the only available solution for IPv6 interdomain
   ASM. Embedded-RP requires an IPv6 multicast address assignment
   mechanism, as multicast addresses mapping to the RP cannot be guessed
   and manually built by users. This is depicted in section 2.1.2 of the
   IETF working group document draft-ietf-mboned-addrarch [13].

This document proposes a simple solution to assign IPv6 multicast
   addresses or prefixes using the DHCPv6 protocol [8].

1.1  IPv6 multicast deployment status

The document draft-jdurand-ipv6-multicast-ra [14] recalls the
   following:

"The deployment of IPv6 multicast is expanding. Some networks have
   already put the service in production. Some gateways have been
   deployed, making it possible to have interoperability between IPv4
   and IPv6 multicast. Some sites have even stopped IPv4 multicast, due
   to its complexity (due to NAT and MSDP for example) and only rely on
   IPv6 multicast, using the deployed gateways for interoperability with
   IPv4.

As of this writing, most sessions are created manually from
   unicast-prefix based address space [6], or use SDR to form a
   semi-random address. Nevertheless these addresses cannot fit with
   embedded-RP [11] which is the only existing solution for IPv6
   interdomain ASM.

Some people argue that SSM solves the problem but there is nowadays a
   demand from customers to be capable to have multicast sessions (both
   IPv4 and IPv6) with multiple sources (e.g., conferencing) and it is
   not clear how to achieve this with SSM. While "multiple-source SSM"
   could potentially be done with the aid of SIP or RTP, this does not
   exist yet, and a simple solution for ASM is needed."

1.2  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

1.3  SSM: no solution needed

In the SSM model, as the channel is defined by the tuple (source
   address , group address), a collision can only occur if a host would
   like to be a sender for 2 different groups having the same address.

Durand                  Expires August 19, 2005                 [Page 3]
 
Internet-Draft    IPv6 multicast address assignment with DHCPv6        February 2005

Therefore, it is sufficient for a sender to choose different
   addresses for different channels, this is a decision local to the
   host. This document only considers the ASM model which is a bit more
   complex.

1.4  Session announcement considerations

This document does not address the session announcement problem. It
   only answers the question of large scale address assignemnt of IPv6
   multicast addresses. Announcement of the sessions can still be done
   using web pages, emails, directories, SAP, etc.

2.  State of the art for address assignment

MADCAP [2] solves, or could solve, the multicast address assignment
   problem for both IPv4 and IPv6. However, MADCAP is a fork of DHCP, it
   has only a couple of implementations which have not been widely
   deployed. We assume that a mechanism that would be a simple extension
   to a more widely available mechanism (DHCPv6) could be more deployed.

This proposal and draft-jdurand-ipv6-multicast-ra [14] simplify the
   assignment architecture since the unicast and multicast address
   assignment mechanisms become the same. We consider at this stage only
   IPv6 multicast since most of the key elements used are already
   defined, and interaction with IPv4 multicast is ensured. If felt
   needed by the community, this proposal could be extended to IPv4.

3.  Assignment with DHCPv6

3.1  New DHCPv6 options

This section introduces new options for IPv6 multicast address
   assignment with DHCPv6.

3.1.1  IA_MA option for IPv6 Multicast Addresses

RFC 3315 [8] defines the following options for Identity Associations
   (IA):

o  IA_NA option for Non temporary Addresses

o  IA_TA option for Temporary Addresses

This document introduces a third option: the IA_MA option for IPv6
   Multicast Addresses. This option is used to carry an IA_MA, the
   parameters associated with the IA_MA, and the addresses associated
   with the IA_MA. The format of the IA_MA option is:

Durand                  Expires August 19, 2005                 [Page 4]
 
Internet-Draft    IPv6 multicast address assignment with DHCPv6        February 2005

0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          option-code          |          option-len           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                        IAID (4octets)                         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         .                         IA_MA-options                         .
         .                                                               .
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code: OPTION_IA_MA (TBD)

option-len: 4 + length of IA_MA-options field

IAID: The unique identifier for this IA_MA; the IAID must be unique
      among the identifiers for all of this client's IA_MAs. The number
      space for IA_MA IAIDs is separate from the number space for IA_NA
      and IA_TA IAIDs

IA_MA-Options: Options associated with this IA_MA

The IA_MA-options field encapsulates those options that are specific
   to this IA_MA. For example, all of the IA Address Options carrying
   the multicast addresses associated with this IA_MA are in the
   IA_MA-options field.

Each IA_MA carries one "set" of multicast addresses; that is, at most
   one address per session created by the client requiring an address.

An IA_MA option may only appear in the options area of a DHCP
   message. A DHCP message may contain multiple IA_MA options. The
   status of any operations involving this IA_MA is indicated in a
   Status Code option in the IA_MA-options field.

Note that an IA has no explicit "lifetime" or "lease length" of its
   own. When the valid lifetimes of all of the addresses in an IA_MA
   have expired, the IA can be considered as having expired.

An IA_MA option does not include values for T1 and T2 (see RFC 3315
   [8]). A client MAY request that the lifetimes of multicast addresses
   be extended by including the addresses in a IA_MA option sent in a
   Renew or Rebind message to a server. For example, a client would
   request an extension on the lifetime of a multicast address to allow
   an application to continue a multicast session.

The client obtains new multicast addresses by sending an IA_MA option

Durand                  Expires August 19, 2005                 [Page 5]
 
Internet-Draft    IPv6 multicast address assignment with DHCPv6        February 2005

with a new IAID to a server. The server will generate new multicast
   addresses and return them to the client. In case the clients needs to
   extend the multicast session, it sends a Renew message to the server
   with the IA_MA and addresses in parameters.

3.1.2  Scope Option for IPv6 multicast address

The scope option for IPv6 multicast addresses is used by the clients
   to request multicast addresses with a certain scope. It is included
   in the IA address option IAaddr-options field defined in section 22.5
   of RFC 3315 [8]. A user can attach more than one scope option for
   IPv6 multicast address to an IA address option if the client does not
   know exactely the scope it wants to request but has a set of adequate
   scope values.

0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         OPTION_SCOPE          |          option-len           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | scope |  res  |
       +-+-+-+-+-------+

option-code: OPTION_SCOPE (TBD)

option-len: 1

scope: The scope value for the requested IPv6 multicast address,
      according to values defined in RFC 3513 [9]

res: This field is reserved for future use. The 4 bits of this field
      MUST be set to 0, and MUST be ignored on receipt

3.2  Address timers

NOTE: There have been some discussions about using some options for
   the timers. This is let to next releases of the document as this
   release really focuses on why an assignment based on DHCPv6 has an
   interest.

The IA address option defined in RFC 3315 [8] contains the following
   32 bits fields:

o  preferred-lifetime: The preferred lifetime for the IPv6 address in
      the option, expressed in units of seconds

o  valid-lifetime: The valid lifetime for the IPv6 address in the

Durand                  Expires August 19, 2005                 [Page 6]
 
Internet-Draft    IPv6 multicast address assignment with DHCPv6        February 2005

option, expressed in units of seconds

We suggest to use these fields, usually defined for unicast
   addresses, for IPv6 multicast addresses, with the definition written
   above.

The maximum value for these lifetimes is 2^32 seconds or 49710 days
   equivalent to 136 years. Therefore a host that wants to be assigned
   an address for a 2 days session occuring in 30 days can request an
   address with a preferred lifetime value of 32 days. According to the
   IPv6 multicast addressing space available, servers should allow this
   type of requests, or at least should permit a certain number of
   long-term assignment per host. The address is directly assigned by
   the DHCP server when the request is received. We suggest here not
   using the parameters minDesiredStartTime and maxDesiredStartTime
   specified in RFC 2771 [3] which bring too much complexity for the
   assignment and don't really make sense for IPv6 where many addresses
   are available.

3.3  Assignment of a multicast prefix

The assignment of a multicast prefix can be needed in the following
   scenarios:

o  An ISP needs to assign a block of IPv6 multicast address to an
      enterprise, assigning IPv6 multicast addresses to its hosts. This
      scenario will most likely occur when DHCPv6 prefix delegation [10]
      is already used to assign unicast prefixes to the enterprise.

o  Also it is most likely that the multicast applications will not
      support at the beginning the API to request for an IPv6 multicast
      address via DHCPv6. Then, on startup, or when connected to a new
      network, a host could ask for an IPv6 multicast prefix.
      Applications could then choose locally multicast addresses in the
      prefix assigned to the host.

To fulfill this need, the prefix delegation mechanism described in
   RFC 3633 [10] is needed also for multicast prefixes. The actual
   specifications of the IPv6 prefix Options for DHCPv6 do not need to
   be changed to support multicast prefix delegations. The only thing to
   keep in mind is that multicast prefix delegation can also occur
   between a router and a host to fulfill the second requirement
   mentioned above.

3.4  Client and server behavior

The procedures to request an IPv6 multicast address is more or less
   the same than the ones described in RFC 3315 [8] to request a

Durand                  Expires August 19, 2005                 [Page 7]
 
Internet-Draft    IPv6 multicast address assignment with DHCPv6        February 2005

temporary IPv6 address. The differences are following:

o  The client uses IA-type IA_MA described above to ask for IPv6
      multicast addresses.

o  The client SHOULD use the Scope Option in solicit and request
      messages to tell the server the scope wanted for the IPv6
      multicast address requested. It can include more than one Scope
      Option for IPv6 multicast address per addresses requested in case
      the client does not know exactly the scope it wants to request but
      has a set of adequate scope values.

o  The client SHOULD specify the lifetimes for every address it wants
      to be assigned in solicit, request, renew and rebind messages.

o  The server MUST assign addresses only if it can assign an address
      matching one of the scope requested. In case the server can't
      assign an address with the requested scopes, it must include the
      Status Code Option NoAddrsAvail in the advertise and reply
      messages and should include a status message with the scopes that
      can be assigned by the server and their description.

o  If no scope option is specified by the client, the server can
      assign a multicast address with any scope. It can be a default
      scope value configured by the DHCP server administrator.

4.  Group-ID consideration

RFC 3307 [7] defines guidelines for the choice of IPv6 multicast
   group identifier (the last 32 bits of the IPv6 multicast address). It
   specifies that for dynamic IPv6 multicast address allocation, the
   group-ID MUST be in the range 0x80000000 to 0xFFFFFFF.

5.  Deployment scenarios - Case studies

This section gives examples of DHCPv6 deployments for IPv6 multicast
   address assignment.

5.1  Scenario 1: Site deployment

Consider a site having configured a DHCPv6 server and having one RP
   for a site-local scope (scope 5). In this simple scenario, the DHCPv6
   server can assign the complete set of addresses with a site-local
   scope.

We have the same scenario if the site configures one RP for global
   scope with embedded-RP technology. The DHCPv6 server of the site can

Durand                  Expires August 19, 2005                 [Page 8]
 
Internet-Draft    IPv6 multicast address assignment with DHCPv6        February 2005

assign the complete set of addresses derived from the RP's address
   (see Embedded-RP [11]).

5.2  Scenario 2: Campus deployment

Consider a campus having configured one DHCPv6 server for the entire
   site, and having several labs (in different subnets) having each a
   multicast scope for their own usage. Every lab might have for example
   a scope admin-local (scope 4), and the campus may have the scope
   site-local (scope 5). The problem of the DHCPv6 server is to assign
   appropriate addresses to each of the labs.

The server can retrieve information about the location of the client
   according to the explanation given in section 11 of RFC 3315 [8]. The
   server can determine this way in which lab the client is and assign
   adequate addresses. This way a server can assign the same address
   twice to different clients in different labs.

5.3  Scenario 3: ISP deployment

Consider an ISP providing a global RP service to its customers. The
   ISP decided to use embedded-RP technology for this RP. Every
   customers having configured a DHCPv6 server would like to assign IPv6
   multicast addresses based on the RP of their ISP. The problem is to
   avoid overlap between addresses assigned by every DHCPv6 servers.

In this scenario, the ISP having configured an RP would allocate a
   range of IPv6 multicast addresses based on its RP to every customer
   having subscribed for the service (as explained in section 5.2 of
   Embedded-RP [11]). This allocation could be typically hand-off
   allocation, as it is done between ISP and big customers (not
   end-users at home) for unicast or could be done with DHCPv6 prefix
   delegation as explained in this document. This way, every DHCPv6
   server is then configured with a different multicast address range,
   all matching the same RP. This means that ISPs need to allocate IPv6
   multicast addresses to their customers, as they do today for IPv6
   unicast. Address allocation architectures are exactly the same.
   Nevertheless, we can note that any customer could deploy its own
   embedded-RP rather than using the one of its ISP, which simplifies
   this scenario.

6.  Security considerations

The security considerations related to the DHCPv6 protocol are
   discussed in the security considerations section of [8].

Durand                  Expires August 19, 2005                 [Page 9]
 
Internet-Draft    IPv6 multicast address assignment with DHCPv6        February 2005

7.  Acknowledgement

The author would like to thank Bernard Tuy, Stig Venaas, Christian
   Strauf, Pekka Savola and Dave Thaler for their good contributions to
   this memo. The author would also like to thank Ralph Droms who took
   time to consider the IPv6 multicast assignment problem and introduced
   the concept of the identity association for IPv6 multicast addresses.
   The author would also like to thank all the people having worked on
   the 6NET Deliverable 3.4.3 [12], which was the initial document that
   raised the complete problematic of IPv6 multicast address assignment.

Pekka Savola, Dave Thaler, Stig Venaas and Bernard Tuy have
   contributed to better state the problem and mention why the proposal
   is of interest.

8.  Discussions

Here are the current discussions and questions about this document:

o  Timers could be specified with a new DHCPv6 option rather than
      overloading the timers of the address

o  If the server cannot assign addresses for the required scopes, it
      could assign an address in any other scope it is configured for.

9.  Changes from -00

o  Clarification of the need for the proposal

o  The multicast address assignment state of the art is now let to
      ID.draft-ietf-mboned-addrarch [13].

o  IPv6 multicast prefix delegation is now supported by this
      mechanism, from comments received in IETF 60th.

10.  References

10.1  Normative references

[1]   S. Bradner, "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, March 1997.

[2]   S. Hanna, B. Patel and M. Shah, "Multicast Address Dynamic
         Client Allocation Protocol (MADCAP)", RFC 2970, December 1999.

[3]   R. Finlayson, "An Abstract API for Multicast Address

Durand                  Expires August 19, 2005                [Page 10]
 
Internet-Draft    IPv6 multicast address assignment with DHCPv6        February 2005

Allocation", RFC 2771, February 2000.

[4]   M. Handley, C. Perkins and E. Whelan, "Session Announcement
         Protocol (SAP)", RFC 2974, October 2000.

[5]   D. Meyer and P. Lothberg, "GLOP Addressing in 233/8", RFC 3180,
         September 2001.

[6]   B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6 Multicast
         Addresses", RFC 3306, August 2002.

[7]   B. Haberman, "Allocation Guidelines for IPv6 Multicast
         Addresses", RFC 3307, August 2002.

[8]   R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M.
         Carney, "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", RFC 3315, July 2003.

[9]   R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6)
         Addressing Architecture", RFC 3513, April 2003.

[10]  O. Troan, R. Droms, "IPv6 Prefix Options for Dynamic Host
         Configuration Protocol (DHCP) version 6", RFC 3633, December
         2003.

[11]  P. Savola and B. Haberman, "Embedding the Rendezvous Point (RP)
         Address in an IPv6 Multicast Address", November 2004.

10.2  Informative references

[12]  6NET project partners, "6NET D3.4.3 - IPv6 multicast address
         allocation study", May 2003.

[13]  P. Savola, "Overview of the Internet Multicast Addressing
         Architecture", November 2004.

[14]  J. Durand and P. Savola, "RA for IPv6 multicast prefixes",
         February 2005.

Durand                  Expires August 19, 2005                [Page 11]
 
Internet-Draft    IPv6 multicast address assignment with DHCPv6        February 2005

Author's Address

Jerome Durand
   GIP RENATER
   151 Bd de l'Hopital
   Paris  75013
   France

Phone: +33 1 53 94 20 30
   EMail: Jerome.Durand@renater.fr

Durand                  Expires August 19, 2005                [Page 12]
 
Internet-Draft    IPv6 multicast address assignment with DHCPv6        February 2005

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
 Internet Society.</pre>

IPv6 multicast address assignment with DHCPv6

Network Working Group J. Durand Internet-Draft GIP RE...

Converting IPv4 addresses to IPv6 addresses

Tukiyooo 0 Converting, Easy Explanation Of IPv4, Internet Protocol Version4 and IPv6, IPv4, IPv4/IPv6, Setup IPv6 19:08

Converting IPv4 addresses to IPv6 addresses
 
-------------------------------------------
 
Here's a cool tool for doing it in windows:
 
<a href="http://www.softpedia.com/get/network-tools/ip-tools/ipconvert.shtml" rel="nofollow">http://www.softpedia.com/get/Network-Tools/IP-Tools/IPConvert.shtml</a>

Here's the main ipv6 website:

There's a good read at Microsfoft on tcp/ip
 
fundamentals and subnetting:

<a href="http://www.microsoft.com/technet/itsolutions/network/evaluate/" rel="nofollow">http://www.microsoft.com/technet/itsolutions/network/evaluate/</a>
 
technol/tcpipfund/tcpipfund_ch04.mspx#EEIAG

Here are some OpenBSD related sites:

<a href="http://www.inet6.dk/config/openbsd.html" rel="nofollow">http://www.inet6.dk/config/openbsd.html</a>
 
<a href="http://www.sans.org/reading_room/whitepapers/firewalls/807.php" rel="nofollow">http://www.sans.org/reading_room/whitepapers/firewalls/807.php</a>

I'm sure there are scads more. Google is your friend! ;)

Here are a few more, more general or linux:

<a href="http://enterprisenetworkingplanet.com/netsp/article.php/3634596" rel="nofollow">http://enterprisenetworkingplanet.com/netsp/article.php/3634596</a>
 
<a href="http://enterprisenetworkingplanet.com/netsp/article.php/3629546" rel="nofollow">http://enterprisenetworkingplanet.com/netsp/article.php/3629546</a>
 
<a href="http://enterprisenetworkingplanet.com/netsp/article.php/3633211" rel="nofollow">http://enterprisenetworkingplanet.com/netsp/article.php/3633211</a>

The examples below are pretty simple Class C
 
network examples. I put several sequential
 
addresses in order to show the progression
 
in IPv6 notation.

--------------------------------------------
 
IPV4 Address: 192.168.1.100

IPV6 Address:

IPv6 Full Address
 
0000:0000:0000:0000:0000:0000:C0A8:0164

IPv6 Shorthand Adress:
 
::C0A8:0164

IPv6 & Dot Notation Full Address:
 
0000:0000:0000:0000:0000:0000:192.168.1.100

IPv6 & Dot Notation Shorthand Adress:
 
192.168.1.100
 
--------------------------------------------

--------------------------------------------
 
IPV4 Address: 192.168.1.101

IPV6 Address:

IPv6 Full Address
 
0000:0000:0000:0000:0000:0000:C0A8:0165

IPv6 Shorthand Adress:
 
::C0A8:0165

IPv6 & Dot Notation Full Address:
 
0000:0000:0000:0000:0000:0000:192.168.1.101

IPv6 & Dot Notation Shorthand Adress:
 
192.168.1.101
 
--------------------------------------------

--------------------------------------------
 
IPV4 Address: 192.168.1.102

IPV6 Address:

IPv6 Full Address
 
0000:0000:0000:0000:0000:0000:C0A8:0166

IPv6 Shorthand Adress:
 
::C0A8:0166

IPv6 & Dot Notation Full Address:
 
0000:0000:0000:0000:0000:0000:192.168.1.102

IPv6 & Dot Notation Shorthand Adress:
 
192.168.1.102
 
--------------------------------------------

--------------------------------------------
 
IPV4 Address: 192.168.1.103

IPV6 Address:

IPv6 Full Address
 
0000:0000:0000:0000:0000:0000:C0A8:0167

IPv6 Shorthand Adress:
 
::C0A8:0167

IPv6 & Dot Notation Full Address:
 
0000:0000:0000:0000:0000:0000:192.168.1.103

IPv6 & Dot Notation Shorthand Adress:
 
192.168.1.103
 
--------------------------------------------

--------------------------------------------
 
IPV4 Address: 192.168.1.104

IPV6 Address:

IPv6 Full Address
 
0000:0000:0000:0000:0000:0000:C0A8:0168

IPv6 Shorthand Adress:
 
::C0A8:0168

IPv6 & Dot Notation Full Address:
 
0000:0000:0000:0000:0000:0000:192.168.1.104

IPv6 & Dot Notation Shorthand Adress:
 
192.168.1.104
 
----------------------

Converting IPv4 addresses to IPv6 addresses

Converting IPv4 addresses to IPv6 addresses ------------------------------------------- Here's a cool tool for doing it in windows: h...

World IPv6 day (Test Flight)

Solving the IP Address Chicken-and-Egg Challenge

C++ Internet Protocol and Socket Address Classes

What is tunneltrace?

How to add IPv6 over IPv4 support to your network behind a NAT router

IPv6 multicast address assignment with DHCPv6

Converting IPv4 addresses to IPv6 addresses

ADV

Populars

Arsip Blog